Alt om ingenting og litt i mellom » integritet

Fortsetter jakten på MySQL-features

Knut-Olav — Thu, 05 Nov 2009 21:17:08 +0000

I dag kom jeg over noe merkelige greier i MySQL.

I en SELECT-spørring hvor jeg bruker WHERE for å søke etter strenger, så betyr det ingenting om jeg spør mot en tom streng eller masse mellomrom.

Jeg har en tabell som heter “texts” med kolonnene “uuid”, “name” og “content”. Feltet “content” er av type TEXT fordi jeg har behov for å lagre et ukjent antall tegn med tekst her.


+--------------+--------------+------+-----+---------+-------+
| Field        | Type         | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+-------+
| uuid         | varchar(36)  | NO   | PRI |         |       |
| name         | varchar(16)  | NO   |     |         |       |
| content      | text         | NO   |     |         |       |
+--------------+--------------+------+-----+---------+-------+

Først testet jeg med en tom streng:


mysql> SELECT uuid,name,content FROM texts \
    -> WHERE content = "";
+--------------------------------------+-------------+---------+
| uuid                                 | name        | content |
+--------------------------------------+-------------+---------+
| 1b74168e-5b91-4c27-b1eb-257d6d0cee18 | description |         |
| 963c7f0a-e0dc-45e5-af5b-a803dee3a743 | arrival     |         |
| a7bf022e-fc95-4410-bd6e-e92b64f12db4 | regulation  |         |
| ebffc5bb-b3f8-473d-8f34-a5041f73987c | sanitation  |         |
+--------------------------------------+-------------+---------+
4 rows in set (0.00 sec)

Deretter forsøkte jeg bare for moro skyld å søke etter tre mellomrom:


mysql> SELECT uuid,name,content FROM texts \
    -> WHERE content = "   ";
+--------------------------------------+-------------+---------+
| uuid                                 | name        | content |
+--------------------------------------+-------------+---------+
| 1b74168e-5b91-4c27-b1eb-257d6d0cee18 | description |         |
| 963c7f0a-e0dc-45e5-af5b-a803dee3a743 | arrival     |         |
| a7bf022e-fc95-4410-bd6e-e92b64f12db4 | regulation  |         |
| ebffc5bb-b3f8-473d-8f34-a5041f73987c | sanitation  |         |
+--------------------------------------+-------------+---------+
4 rows in set (0.00 sec)

Men for all del da? Dette er jo samme resultatet som ovenfor.

Eller hva med denne spørringen? Jeg kan ikke skjønne hvorfor det er slik. En tom streng er ikke det samme som tre spacer!


mysql> SELECT uuid,name,content FROM texts \
    -> WHERE content = "   " AND content = "";
+--------------------------------------+-------------+---------+
| uuid                                 | name        | content |
+--------------------------------------+-------------+---------+
| 1b74168e-5b91-4c27-b1eb-257d6d0cee18 | description |         |
| 963c7f0a-e0dc-45e5-af5b-a803dee3a743 | arrival     |         |
| a7bf022e-fc95-4410-bd6e-e92b64f12db4 | regulation  |         |
| ebffc5bb-b3f8-473d-8f34-a5041f73987c | sanitation  |         |
+--------------------------------------+-------------+---------+
4 rows in set (0.00 sec)

Hvorfor i alle dager gjør MySQL dette her mot meg?

Én teori jeg har er at MySQL skal hjelpe meg som en dum utvikler i å returnere det korrekte svaret selv om jeg skulle skrevet inn et mellomrom for mye i søkefeltet mitt. Akkurat i samme stil som de andre gangene MySQL har vært så hjelpsom mot meg…

MySQL på nye fremmednøkkeleventyr

Knut-Olav — Tue, 13 Oct 2009 20:23:17 +0000

Ikke så lenge siden skrev jeg om MySQL sine problemer med datatyper og NULL-konstraints. Og problemene stopper ikke der.

Jeg kom i dag over en merkelig og helt uforståelig bug i MySQL. Eller, det heter vel kanskje feature når det gjelder MySQL.

Ta følgende scenario: En kolonne “disabled_reason_ref” i tabellen “countries” refererer til feltet “uuid” i tabellen “texts”. Kolonnen “disabled_reason_ref” er definert med mindre størrelse enn feltet den refererer til. Dette visste jeg ikke om. Begge tabellene bruker InnoDB og det er satt opp fremmednøkler. Hvordan dette gir noe som helst mening i MySQL-verden vet jeg ikke.

Ihvertfall. Det hele startet med denne SQL INSERT-spørringen.


mysql> INSERT INTO countries (uuid, country_code, disabled, disabled_reason_ref, page_ref) VALUES ("a63d5a26-9719-47dd-9617-c07bd8126061", "NO", 1, "e80c8d7c-dd84-4a4f-8df4-778efe9b311a", NULL);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`utenlandsbolig/countries`, CONSTRAINT `countries_ibfk_2` FOREIGN KEY (`disabled_reason_ref`) REFERENCES `texts` (`uuid`))

Det er ingenting i feilmeldingen fra denne spørringen som sier noe om det.

Jeg lurte litt på om kolonnenavnet var for langt, så jeg lagde en ny kolonne som heter “reason_ref”.


mysql> alter table countries add column  reason_ref VARCHAR(32)  REFERENCES texts(uuid);
Query OK, 1 row affected (0.52 sec)
Records: 1  Duplicates: 0  Warnings: 0

MySQL satte riktignok ikke opp noen fremmednøkkel her, noe jeg sjekket med “SHOW CREATE TABLE countries”.
Lurer da fælt på hva den i så fall referer til…
Vel, MySQL er MySQL.

Jeg tenkte så at jeg ikke trengte “disabled_reason_ref” lenger.


mysql> alter table countries drop column disabled_reason_ref;
ERROR 1025 (HY000): Error on rename of './utenlandsbolig/#sql-4fa3_6' to './utenlandsbolig/countries' (errno: 150)

Hva i alle dager betyr dette?
Jeg kom meg ikke rundt feilen, så jeg lot kolonnen bare ligge.

Jeg hadde på dette tidspunktet ikke oppdaget at “reason_ref” var for liten. Kolonnen den refererer til er nemlig av type VARCHAR(36).

Et nytt forsøk på INSERT, nå ved å bruke den nye kolonnen.


mysql> INSERT INTO countries (uuid, country_code, disabled, reason_ref, page_ref) VALUES ("a63d5a26-9719-47dd-9617-c07bd8126061", "NO", 1, "e80c8d7c-dd84-4a4f-8df4-778efe9b311a", NULL);
Query OK, 1 row affected, 1 warning (0.19 sec)

mysql> show warnings;
+---------+------+-------------------------------------------------+
| Level   | Code | Message                                         |
+---------+------+-------------------------------------------------+
| Warning | 1265 | Data truncated for column 'reason_ref' at row 1 |
+---------+------+-------------------------------------------------+
1 row in set (0.00 sec)

Og det viste seg at kolonnen var for liten. Dermed fant den ingen rad i “texts”-tabellen som hadde den refererte verdien på 32 tegn, da verdien egentlig skulle vært på 36 tegn.


mysql> alter table countries modify column disabled_reason_ref varchar(36);
Query OK, 2 rows affected (0.40 sec)
Records: 2  Duplicates: 0  Warnings: 0

Greit at det var jeg som gjorde feilen med å deklarere kolonnen for liten.
Men hallooo, litt hjelp kan man vel få fra en database? Spesielt fra en relasjonsdatabase!

Dumme MySQL!

MySQL – mangel på integritet

Knut-Olav — Sat, 03 Oct 2009 09:55:36 +0000

MySQL gjør mye rart. Her har vi en ganske normal tabell, med kolonner som krever en verdi og med kolonner av forskjellige datatyper. Fire av kolonnene i tabellen kan ta default verdier, resten kan det ikke.


mysql> DESC user_status;
+-------------------+--------------+------+-----+---------+-------+
| Field             | Type         | Null | Key | Default | Extra |
+-------------------+--------------+------+-----+---------+-------+
| uid               | int(10)      | NO   | PRI | NULL    |       |
| verified          | tinyint(1)   | NO   |     | 0       |       |
| registered_nick   | tinyint(1)   | NO   |     | 0       |       |
| first_time        | tinyint(1)   | NO   |     | 1       |       |
| registration_date | datetime     | NO   |     | NULL    |       |
| verification_code | int(10)      | NO   |     | NULL    |       |
| nick              | varchar(32)  | NO   |     | NULL    |       |
| active            | tinyint(1)   | NO   |     | 1       |       |
| ban_reason        | varchar(255) | NO   |     | NULL    |       |
| logincount        | int(11)      | NO   |     | NULL    |       |
| lastlogin         | datetime     | NO   |     | NULL    |       |
+-------------------+--------------+------+-----+---------+-------+

Så legger vi inn en rad i tabellen. Legg merke til at vi bare legger inn data i noen av kolonnene.


INSERT INTO user_status(
  uid, verified, registration_date,
  verification_code, nick)
VALUES(1, 1, NOW(), "asd", "ut");

Så får jeg en suksessmelding tilbake fra MySQL, jippi. Eller vent, det står noe om at det er generert tre advarsler. Ok tenker jeg, så jeg får vel finne ut hva disse advarslene er.


mysql> SHOW WARNINGS;
+---------+------+------------------------------------------------------------------------+
| Level   | Code | Message                                                                |
+---------+------+------------------------------------------------------------------------+
| Warning | 1364 | Field 'ban_reason' doesn't have a default value                        |
| Warning | 1364 | Field 'logincount' doesn't have a default value                        |
| Warning | 1364 | Field 'lastlogin' doesn't have a default value                         |
| Warning | 1366 | Incorrect integer value: 'asd' for column 'verification_code' at row 1 |
+---------+------+------------------------------------------------------------------------+

Det at MySQL gir blaffen i påkrevde kolonner visste jeg egentlig, og jeg blir sinna hver gang jeg tenker på det. Så egentlig var de første advarslene godt kjente for meg.

Det som virkelig overrasket meg var,

Hva?! Tillater MySQL meg å opprette en rad i en tabell med noe data i en kollonne med en annen datatype?

MySQL tillater meg faktisk å sende inn tekststrengen “asd” inn kolonnen “verification_code” som er deklarert som et heltall. Hva i alle dager? Hvilken verdi har MySQL satt inn i tabellen min da? Dette må undersøkes.


mysql> SELECT * FROM user_status;
+-----+----------+-----------------+------------+---------------------+-------------------+------+--------+------------+------------+---------------------+
| uid | verified | registered_nick | first_time | registration_date   | verification_code | nick | active | ban_reason | logincount | lastlogin           |
+-----+----------+-----------------+------------+---------------------+-------------------+------+--------+------------+------------+---------------------+
|   1 |        1 |               0 |          1 | 2009-09-29 17:08:57 |                 0 | ut   |      1 |            |          0 | 0000-00-00 00:00:00 |
+-----+----------+-----------------+------------+---------------------+-------------------+------+--------+------------+------------+---------------------+

Den satte inn tallet “0″ i verification_code-kolonnen. Hvordan MySQL fant ut at det var en smart idé vet jeg ikke. Kolonnen er av type heltall, den krever en verdi og er deklarert uten noen default verdi. Jeg sender inn tekststrengen “asd”.

I et scriptspråk som PHP eller Perl evalueres denne strengen til en bolsk sann verdi. Så kanskje kunne heltallsrepresentasjonen av strengen vært “1″. Derimot er det ikke sikkert at kolonnen representerer en bolsk verdi, for da ville jeg vel brukt en datatype som bit eller bool, ikke sant? Det eneste fornuftige å gjøre er faktisk å ikke tillate verdien og forhindre meg i å opprette raden.

Det jeg stusser litt på, og blir lei meg over, er den manglende forståelsen av integritet i MySQL. Hvis jeg forsøker å opprette en rad i en tabell uten å sende inn alle påkrevde felt, så burde jeg ikke få lov til å opprette raden. Så enkelt kan det gjøres.

MySQL må ikke tro at den er smartere enn meg.