Mystiken in MySQL

[akretschmer]

Man beachte was ich tue, und versuche bitte mir zu erklären, was hier passiert. Wer das schafft, bekommt einen virtuellen Bonbon, also strengt Euch an!

mysql> create table lacido (datum timestamp);
Query OK, 0 rows affected (0.00 sec)         

mysql> insert into lacido (datum) values ('1362256218');
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> select * from lacido;
+---------------------+
| datum               |
+---------------------+
| 0000-00-00 00:00:00 |
+---------------------+
1 row in set (0.00 sec)

mysql> alter table lacido add column d datetime;
Query OK, 1 row affected (0.01 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> select * from lacido;
+---------------------+------+
| datum               | d    |
+---------------------+------+
| 0000-00-00 00:00:00 | NULL |
+---------------------+------+
1 row in set (0.00 sec)

mysql> update lacido set d = from_unixtime(datum);
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from lacido;
+---------------------+---------------------+
| datum               | d                   |
+---------------------+---------------------+
| 2013-03-02 21:35:38 | 1970-01-01 01:00:00 |
+---------------------+---------------------+
1 row in set (0.00 sec)

mysql>

Welche Magie steckt hier dahinter, daß die Spalte Datum nach dem ersten Insert ein nicht eingegebenes 0000-00-00 anzeigt, und nach dem Update der anderen Spalte plötzlich den korrekten wert? Wie krank bitte ist das denn, oder hab ich komplett was verpeilt?

Okay, Version ist nicht ganz frisch, 5.0.75.

Kann das mal jemand nachvollziehen oder gar erklären?

geht übrigens weiter:

mysql> select * from lacido;
+---------------------+---------------------+
| datum | d |
+---------------------+---------------------+
| 2013-03-02 21:35:38 | 1970-01-01 01:00:00 |
+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> update lacido set d = from_unixtime(datum);
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from lacido;
+---------------------+------+
| datum | d |
+---------------------+------+
| 2013-03-02 21:46:04 | NULL |
+---------------------+------+
1 row in set (0.00 sec)

Ich glaub, ich muß meine Vorurteile gegen MySQL überarbeiten: es ist NOCH SCHLIMMER, als angenommen.

Andreas

 

[tibi38]

Hallo Andreas,
was ist denn da so sonderbar dran?
schau dir mal das hier an: http://dev.mysql.com/doc/refman/5.1/de/timestamp-4-1.html

Wenn du also deinen Server nicht entsprechend eingestellt hast, so wird timestamp mit Null initiert.
Nach dem Schreiben des Datum-Wertes wird dann der Wert auf das aktuelle Datum+Zeit gesetzt.
Dein Schreiben danach wird auf d mit dem falschen Wert (timestamp ist ein Char-19 - Feld und kein Unix-timestamp) ergibt dann dort im feld d wieder Null.
Alles hättest du selber rausfinden können, wenn du dir die Warnings angeschaut hättest.
Grüße
TiBi

 

[akretschmer]

Hallo Andreas,
was ist denn da so sonderbar dran?

Sonderbar finde ich, daß bei einem Update des Feldes X mal so nebenbei auch in einem anderen Feld, welches ich nicht update, der Wert sind ändert.
Aber ich glaub jetzt fällt der Groschen: die erste timestamp-Spalte wird immer automatisch aktualisiert, stimmts?

Wenn du also deinen Server nicht entsprechend eingestellt hast, so wird timestamp mit Null initiert.
Nach dem Schreiben des Datum-Wertes wird dann der Wert auf das aktuelle Datum+Zeit gesetzt.

Ja...

Dein Schreiben danach wird auf d mit dem falschen Wert (timestamp ist ein Char-19 - Feld und kein Unix-timestamp) ergibt dann dort im feld d wieder Null.
Alles hättest du selber rausfinden können, wenn du dir die Warnings angeschaut hättest.
Grüße
TiBi

Mag stimmen.

Nun ja, ich nutze MySQL selber nicht. Wenn man von einem anderen System kommt, stolpert man halt über sowas. Mag sein, daß das dokumentiert ist und auch Warnings kamen, aber das Verhalten von mySQL ist irgendwie doch schon sonderbar. Finde ich.

Danke für die Erklärung!

Andreas