Die Fehlermeldung im Apache Log war:

WordPress-Datenbankfehler You have an error in your SQL syntax! Check the manual that corresponds to your MySQL server version for the right syntax to use near ‘-7200) AS UNSIGNED)), ‘%H:00′) as thedate FROM wp_wassup WHERE …

Nachdem ich etwas rumgeschaut hatte, war der böse Code schnell gefunden:

In der Datei “lib/main.php” in Zeile 996 (die übrigens 447 Zeichen lang ist) finden wir 2 mal

FROM_UNIXTIME(CAST((timestamp-$UTCoffset) AS UNSIGNED))

Das ändern wir nun schnell mal um in:

FROM_UNIXTIME(CAST((`timestamp`-$UTCoffset) AS UNSIGNED))

und siehe da… nun klappts auch mit der Grafik… und der Apache bekommt keinen Schluckauf mehr…

Ich vermute das Problem existiert nur mit bestimmten MySQL Versionen (4.0.x?) und das es eigentlich auch reichen müsste das ganze völlig ohne den “cast()” zu schreiben. Denn “timestamp” ist auch ein Keyword… Ich hätte den Namen für ein Feld einfach vermieden… Aber ich mache ja auch keine 447 Zeichen lange Zeilen in meinen Code…

Ansonsten gefällt mir das Plugin ganz gut… aber wenn ich mal wieder Langeweile hab schau ich obs nicht noch was anderes gibt…

Das funktionierte auch Klasse… Anstelle von “20080901121504″ bekommt man dann ein schönes “2008-09-01 12:15:04″ im SELECT angezeigt und wird dies unter MySQL 5 eben auch so bekommen. Damit muss man nicht für beide “Fälle” programmieren.

Damit konnte ich recht elegant meine Software auf die 19 Zeichen vorbereiten und die Kompatibilität der Timestamp betreffenden Programmbereiche für eine später Umstellung auf MySQL 5 sicherstellen!

Heute fand ich nach langem testen ein Problem, welches dieses ganze schöne Vorgehen völlig absurdum fährt:

MySQL 4.0 benutzt eine “TIMESTAMP” deren Feldlänge mit 19 angegeben ist nie als INDEX in einem Query!

Ich konnte es kaum glauben.. aber es ist nach mehrmaligem Testen eindeutig so!

Einfache Demonstration:

CREATE TABLE `test` (
`id` int(11) NOT NULL auto_increment,
`ts1` timestamp(14) NOT NULL,
`ts2` timestamp(19) NOT NULL default ’0000-00-00 00:00:00′,
PRIMARY KEY  (`id`),
KEY `ts1` (`ts1`),
KEY `ts2` (`ts2`)
) TYPE=MyISAM;

INSERT INTO test (id,ts1,ts2) VALUES (NULL , ’20080101120000′, ’20080101120000′);

INSERT INTO test (id,ts1,ts2) VALUES (NULL , ’20080901120000′, ’20080901120000′);

Nun wird bei

EXPLAIN SELECT * FROM test WHERE ts1=’2008-01-01 12:00:00′

der Key “ts1″ benutzt…

bei…

EXPLAIN SELECT * FROM test WHERE ts2=’2008-01-01 12:00:00′

wird der Key “ts2″ nicht benutzt!

Wer Lust hat kann aus Key 1 mal einen timestamp(19) machen .. dann wird ts1 auch nicht mehr benutzt.

Das heißt… durch die Umstellung der TIMESTAMP’s auf timestamp(19) wurden diese in Queries welche eine TIMESTAMP im INDEX als Feld haben plötzlich gar nicht mehr verwendet. So etwas fällt auch unter Umständen nicht sofort auf, gerade wenn man solche mit mehreren Feldern verwendet.

Mag sein, dass dies einigen als “völlig Logisch” bekannt ist… für mich war es eine Erkenntnis die mich erstaunt hat. Ich hatte doch tatsächlich gedacht, dass das Darstellungsformat hier keine Auswirkung hat…