So i'm trying to insert data with the query below. The columns releases_isMultipack, releases_isChase, releases_hasChase and releases_isAssortment are all enum('0', '1') type. 0 and 1 represent false and true.
INSERT INTO releases (releases_uid, releases_title, releases_releaseDate, releases_boxNumber, releases_hobbyDbId, releases_isMultipack, releases_itemNumber, releases_isChase, releases_hasChase, releases_referenceUrl, releases_componentNumber, releases_isAssortment, releases_craftProductId, releases_craftComponentId)
VALUES ('fa4d5128-407a-4c2b-8970-99a36a72b030', 'Woodsy Owl', '2021-03-26T16:05:00-07:00', '', NULL, 0, '52390', 0, 1, 'woodsy-owl-1', '52390a', 0, 9518039, 9518035)
The query works fine, however just leaves the ENUM columns blank even though a value is provided in the insert statement.
Does anyone know why this is happening?
There's a difference between 0 and '0'.
Here's a demo. I get a blank if I insert 0 because that's not the value in the enum.
mysql> create table releases (releases_isMultipack enum('0','1'));
Query OK, 0 rows affected (0.06 sec)
mysql> insert into releases values (0);
Query OK, 1 row affected, 1 warning (0.03 sec)
mysql> show warnings;
+---------+------+-----------------------------------------------------------+
| Level | Code | Message |
+---------+------+-----------------------------------------------------------+
| Warning | 1265 | Data truncated for column 'releases_isMultipack' at row 1 |
+---------+------+-----------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select * from releases;
+----------------------+
| releases_isMultipack |
+----------------------+
| |
+----------------------+
1 row in set (0.00 sec)
But it works if I use '0':
mysql> insert into releases values ('0');
Query OK, 1 row affected (0.03 sec)
mysql> select * from releases;
+----------------------+
| releases_isMultipack |
+----------------------+
| |
| 0 |
+----------------------+
Related
I have a database with a column named date (timestamp) which is set to default CURRENT_TIMESTAMP. This used to work fine, however after migrating the database to a different server the timestamp only gets applied after an UPDATE query is performed, an INSERT query just sets it to "0000-00-00 00:00:00".
I suspect that whatever is doing the insert is putting an empty string into the field. Look at this result;
MariaDB [horizon]> create table foo (t timestamp default current_timestamp not null);
Query OK, 0 rows affected (0.02 sec)
MariaDB [horizon]> insert into foo values ('');
Query OK, 1 row affected, 1 warning (0.01 sec)
MariaDB [horizon]> select * from foo;
+---------------------+
| t |
+---------------------+
| 0000-00-00 00:00:00 |
+---------------------+
1 row in set (0.00 sec)
I would check the code that is doing the insert - if it's coming from a web form the form itself could be submitting an empty string. You really need to insert null or leave the column out of the INSERT to get the default.
MariaDB [horizon]> insert into foo values (null);
Query OK, 1 row affected (0.01 sec)
MariaDB [horizon]> insert into foo values ();
Query OK, 1 row affected (0.00 sec)
MariaDB [horizon]> select * from foo;
+---------------------+
| t |
+---------------------+
| 0000-00-00 00:00:00 |
| 2017-09-19 21:41:16 |
| 2017-09-19 21:41:20 |
+---------------------+
3 rows in set (0.00 sec)
I have to extract data from a MariaDB database where the owners have stored JSON data in varchar fields in the form:
[-100, -18.3, -10.1, 2.2, 5.8, ...]
I would like to be able to select individual entries from each of these JSON encoded text fields.
I have been reading about the many features of JSON support in MariaDB and I have looked at many examples of how data can be stored as JSON in text fields, but they all would require changes to how the data is inserted and/or the schema.
I cannot change the DB in any way. I have ReadOnly access.
The owners of the DB are currently using MariaDB 10.0, but I may be able to get them to upgrade to 10.1
In short, given the following (very simple example), how can I select the 2nd element in the ‘data’ field?
I assume using the JSON features is the way to go (given all the data is JSON), but is there another way? Performance isn't all that important.
MariaDB [mtest]> show columns from cal from mtest;
+-------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| data | varchar(255) | YES | | NULL | |
+-------+--------------+------+-----+---------+-------+
1 row in set (0.00 sec)
MariaDB [mtest]> select * from cal;
+---------+
| data |
+---------+
| [10.1,12.0,16.78,18.9] |
+---------+
1 row in set (0.00 sec)
If you can upgrade to 10.1 (from MariaDB 10.1.9) via CONNECT can use JsonGet_Real function.
Try:
MariaDB [_]> SELECT VERSION();
+-----------------+
| VERSION() |
+-----------------+
| 10.1.14-MariaDB |
+-----------------+
1 row in set (0.00 sec)
MariaDB [_]> INSTALL SONAME 'ha_connect';
Query OK, 0 rows affected (0.01 sec)
MariaDB [_]> CREATE FUNCTION `jsonget_real` RETURNS REAL SONAME 'ha_connect.so';
Query OK, 0 rows affected (0.00 sec)
MariaDB [_]> DROP TABLE IF EXISTS `cal`;
Query OK, 0 rows affected, 1 warning (0.01 sec)
MariaDB [_]> CREATE TABLE IF NOT EXISTS `cal` (
-> `data` VARCHAR(255)
-> );
Query OK, 0 rows affected (0.00 sec)
MariaDB [_]> INSERT INTO `cal`
-> (`data`)
-> VALUES
-> ('[10.1,12.0,16.78,18.9]');
Query OK, 1 row affected (0.00 sec)
MariaDB [_]> SELECT `data` FROM `cal`;
+------------------------+
| data |
+------------------------+
| [10.1,12.0,16.78,18.9] |
+------------------------+
1 row in set (0.00 sec)
MariaDB [_]> SELECT `jsonget_real`(`data`, '[1]', 2) FROM `cal`;
+--------------------------------+
| jsonget_real(`data`, '[1]', 2) |
+--------------------------------+
| 12.00 |
+--------------------------------+
1 row in set (0.00 sec)
I have an INT(3) UNSIGNED column. If I insert a value with character length more that 3, it doesn't clip that value but inserts it.
Whats happening?
FROM What does "size" in int(size) of MySQL mean?
Finally, let's come to the place of the manual where there is the
biggest hint to what the number means:
Several of the data type descriptions use these conventions:
M indicates the maximum display width for integer types. For
floating-point and fixed-point types, M is the total number of digits
that can be stored. For string types, M is the maximum length. The
maximum allowable value of M depends on the data type.
It's about the display width. The weird thing is, though2, that, for
example, if you have a value of 5 digits in a field with a display
width of 4 digits, the display width will not cut a digits off.
If the value has less digits than the display width, nothing happens
either. So it seems like the display doesn't have any effect in real
life.
Now2 ZEROFILL comes into play. It is a neat feature that pads values
that are (here it comes) less than the specified display width with
zeros, so that you will always receive a value of the specified
length. This is for example useful for invoice ids.
So, concluding: The size is neither bits nor bytes. It's just the
display width, that is used when the field has ZEROFILL specified.
mysql> create table a ( a tinyint );
Query OK, 0 rows affected (0.29 sec)
mysql> show columns from a;
+-------+------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| a | tinyint(4) | YES | | NULL | |
+-------+------------+------+-----+---------+-------+
1 row in set (0.26 sec)
mysql> alter table a change a a tinyint(1);
Query OK, 0 rows affected (0.09 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> insert into a values (100);
Query OK, 1 row affected (0.00 sec)
mysql> select * from a;
+-----+
| a |
+-----+
| 100 |
+-----+
1 row in set (0.00 sec)
2 Some code to better explain what I described so clumsily.
mysql> create table b ( b int (4));
Query OK, 0 rows affected (0.25 sec)
mysql> insert into b values (10000);
Query OK, 1 row affected (0.00 sec)
mysql> select * from b;
+-------+
| b |
+-------+
| 10000 |
+-------+
1 row in set (0.00 sec)
mysql> alter table b change b b int(11);
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> select * from b;
+-------+
| b |
+-------+
| 10000 |
+-------+
1 row in set (0.00 sec)
mysql> alter table b change b b int(11) zerofill;
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> select * from b;
+-------------+
| b |
+-------------+
| 00000010000 |
+-------------+
1 row in set (0.00 sec)
mysql> alter table b change b b int(4) zerofill;
Query OK, 1 row affected (0.08 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> select * from b;
+-------+
| b |
+-------+
| 10000 |
+-------+
1 row in set (0.00 sec)
mysql> alter table b change b b int(6) zerofill;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> select * from b;
+--------+
| b |
+--------+
| 010000 |
+--------+
1 row in set (0.00 sec)
actually 3 there is a display width which works for ZEROFILL that pads zero on the right. It doesn't limit the capacity of the integer as it stores upto 4294967295 starting from zero.
example,
CREATE TABLE tableName
(
x INT(3) ZEROFILL NOT NULL,
y INT NOT NULL
);
INSERT INTO tableName (x,y) VALUES
(1, 1),
(12, 12);
SELECT x, y FROM tableName;
Result:
x y
001 1
012 12
Using display width has no effect on how the data is stored. It affects only how it is displayed.
Integer Types (Exact Value)
I think I read that the delete trigger doesn't know what data was deleted and loops over the whole table applying the trigger. Is that true?
Does that mean that the before delete loops over the whole table before the data is deleted and after delete loops over the whole table after the delete occurs?
Is there no way to loop over just the deleted records? So If 10 records are deleted loop over them?
DELIMITER $$
DROP TRIGGER `before_delete_jecki_triggername`$$
CREATE TRIGGER before_delete_triggername
BEFORE DELETE ON table
FOR EACH ROW
BEGIN
/*do stuff*/
END$$
DELIMITER ;
Thanks,
Mat
I think it was due to a confusion with FOR EACH ROW statement.
It is only for "matched records for the statement issued before trigger is invoked."
If there exists N number of records in a table and matches records for where id=x,
assuming x causes a result of less than N records, say N-5, then
FOR EACH ROW causes a loop for N-5 times only.
UPDATE:
A sample test run on the rows affected due to FOR EACH ROW statement is shown below.
mysql> -- create a test table
mysql> drop table if exists tbl; create table tbl ( i int, v varchar(10) );
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.06 sec)
mysql> -- set test data
mysql> insert into tbl values(1,'one'),(2,'two' ),(3,'three'),(10,'ten'),(11,'eleven');
Query OK, 5 rows affected (0.02 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql> select * from tbl;
+------+--------+
| i | v |
+------+--------+
| 1 | one |
| 2 | two |
| 3 | three |
| 10 | ten |
| 11 | eleven |
+------+--------+
5 rows in set (0.02 sec)
mysql> select count(*) row_count from tbl;
+-----------+
| row_count |
+-----------+
| 5 |
+-----------+
1 row in set (0.00 sec)
mysql>
mysql> -- record loop count of trigger in a table
mysql> drop table if exists rows_affected; create table rows_affected( i int );
Query OK, 0 rows affected (0.02 sec)
Query OK, 0 rows affected (0.05 sec)
mysql> select count(*) 'rows_affected' from rows_affected;
+---------------+
| rows_affected |
+---------------+
| 0 |
+---------------+
1 row in set (0.00 sec)
mysql>
mysql> set #cnt=0;
Query OK, 0 rows affected (0.00 sec)
mysql>
mysql> -- drop trigger if exists trig_bef_del_on_tbl;
mysql> delimiter //
mysql> create trigger trig_bef_del_on_tbl before delete on tbl
-> for each row begin
-> set #cnt = if(#cnt is null, 1, (#cnt+1));
->
-> /* for cross checking save loop count */
-> insert into rows_affected values ( #cnt );
-> end;
-> //
Query OK, 0 rows affected (0.00 sec)
mysql>
mysql> delimiter ;
mysql>
mysql> -- now let us test the delete operation
mysql> delete from tbl where i like '%1%';
Query OK, 3 rows affected (0.02 sec)
mysql>
mysql> -- now let us see what the loop count was
mysql> select #cnt as 'cnt';
+------+
| cnt |
+------+
| 3 |
+------+
1 row in set (0.00 sec)
mysql>
mysql> -- now let us see the table data
mysql> select * from tbl;
+------+-------+
| i | v |
+------+-------+
| 2 | two |
| 3 | three |
+------+-------+
2 rows in set (0.00 sec)
mysql> select count(*) row_count from tbl;
+-----------+
| row_count |
+-----------+
| 2 |
+-----------+
1 row in set (0.00 sec)
mysql> select count(*) 'rows_affected' from rows_affected;
+---------------+
| rows_affected |
+---------------+
| 3 |
+---------------+
1 row in set (0.00 sec)
mysql>
Can there any way to insert a hex value into MYSQL?
I also want to be able to retreive it in hex form.
For example, something like:
INSERT INTO table ( hexTag )
VALUES ( HEX(0x41) );
And if I do this, I want it to put an 'A' into the table
For that particular use case, you can either insert the hex value directly and it will be interpreted as a string, or use HEX() to input and UNHEX() to output
mysql> create table hexTable(pseudoHex varchar(50));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into hexTable values (0x41);
Query OK, 1 row affected (0.00 sec)
mysql> select * from hexTable;
+-----------+
| pseudoHex |
+-----------+
| A |
+-----------+
1 row in set (0.00 sec)
mysql> select HEX(pseudoHex) from hexTable;
+----------------+
| HEX(pseudoHex) |
+----------------+
| 41 |
+----------------+
1 row in set (0.00 sec)
mysql> delete from hexTable;
Query OK, 1 row affected (0.00 sec)
mysql> insert into hexTable values (HEX('A'));
Query OK, 1 row affected (0.00 sec)
mysql> select UNHEX(pseudoHex) from hexTable;
+------------------+
| UNHEX(pseudoHex) |
+------------------+
| A |
+------------------+
1 row in set (0.00 sec)
mysql> select * from hexTable;
+-----------+
| pseudoHex |
+-----------+
| 41 |
+-----------+
1 row in set (0.00 sec)
See these links.