CONTENIDO Forum

Hallo zusammen,

es wird daran gearbeitet, CONTENIDO mit dem SQL Modus "NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION" kompatibel zu machen. Während dies für eine Neuinstallation der zukünftigen 4.10.2 klappt (siehe Entwicklungsbranch), gibt es Probleme, wenn man eine vorhandene CONTENIDO Installation aktualisieren möchte. Änderungen an Tabellenstrukturen werden wegen ungültiger Defaultwerte nicht übernommen.

Daher haben wir eine Diskussion auf GitHub, in der die Problematik detaillierter beschrieben ist, inkl. zweier Lösungsansätze. Über eine Beteiligung eurerseits wäre ich sehr erfreut, da mehrere Köpfe verschiedene Vorschläge liefern können...

Zur Diskussion:
https://github.com/CONTENIDO/CONTENIDO/issues/118

Grüße
xmurrix

Tatsächlich ist Datetime nicht banal, weil es gar kein 00.00.00-00:00 gibt: http://www.mysqltutorial.org/mysql-datetime/
Wohingegen Timestamp = 0 ein Datum sein sollte.
Warum dann dieser Wert für dieses Zellenformat erlaubt wurde?
MySQL kann vielleicht die genialen* Datumsberechnungen in einer Tabelle nicht korrekt durchführen, wenn diese Nullen auftauchen. Folglich ist der Strictmode nur logisch.
*wers nicht glaubt, dass die genial sind, kann das ja mal in PHP nachprogrammieren.

Ich habe solche Datenleichen oft so repariert, dass ich einen Robot (Cronjob) über die DB laufen ließ und alle falschen Werte überarbeiten lassen habe.
Da Contenido eher kleine Installationen sind, sollte das auch in einem Setup gehen.
Prüfen kann das auch eine Routine vorher, ob 00.00.00-00:00 vorhanden ist.
Was macht man, wenn das Datum aber 1000-01-01 00:00:00 gesetzt wäre?
Der Vorschlag kam ja, dass es NULL gesetzt werden soll, stattdessen. Wenn das zukünftig mit MySQL so geht, ok.
Weil in Abfragen kann man nachträglich leicht "if(NULL or 00.00.00-00:00)" einbauen, falls die so aufgebaut wäre.
Probleme kriegen eher die, die gleich damit rechnen ohne zu prüfen, was da drin steht.

Die Idee, für die Installation den Strictmode auszusetzen, die ist die pragmatischste, löst aber das Problem nicht auf Dauer.
Man schleppt eigentlich Datenmüll mit.

Wie wäre es mit einem Auswahlfeld nach der Tabellenprüfung, ob man 00.00.00-00:00 beibehalten und nur den Strictmode entschärft haben will oder ob man Datetime Zelleninhalte bei 0 auf NULL setzt?

Hallo Faar,

danke für dein Feedback.

...Was macht man, wenn das Datum aber 1000-01-01 00:00:00 gesetzt wäre?...

In der Branch bug/#106-remove-default-value-current_timestamp-for-database-fields-of-type-datetime gibt es eine Funktion isEmptyDbDateTime(), die das macht, siehe den Commit dazu. Diese Funktion prüft auf, null, leerem String, "0000-00-00 00:00:00", "0000-00-00".

...Die Idee, für die Installation den Strictmode auszusetzen, die ist die pragmatischste, löst aber das Problem nicht auf Dauer...

Stimmt, dadurch hätte man nur die Möglichkeit, das Setup ohne Probleme durchlaufen zu lassen, was nicht bedeutet, dass die Seite danach korrekt funktioniert.

...Probleme kriegen eher die, die gleich damit rechnen ohne zu prüfen, was da drin steht...

Wenn das Setup bei einem Upgrade eigenmächtig die Werte und die NOT NULL Beschränkungen in Datumsfeldern ändert, vor allem bei Modulen und Plugins, die nicht zum CONTENIDO Package gehören, kann das zu Fehlern in den betroffenen Bereichen kommen.

...Wie wäre es mit einem Auswahlfeld nach der Tabellenprüfung, ob man 00.00.00-00:00 beibehalten und nur den Strictmode entschärft haben will oder ob man Datetime Zelleninhalte bei 0 auf NULL setzt?...

Das wäre eine Möglichkeit, die man dem User beim Setup anbieten kann. Ich sehe nur das Problem, dass manche nicht technisch versiert genug sind, um das zu verstehen. Das Setup sollte idealerweise für die User sehr einfach zu bedienen sein. Mir wäre es recht, wenn das Setup alles übernimmt und die Seite danach funktioniert. Bei den Datumsfeldern sehe da bisher leide keine Lösung, die das schafft.

Gruß
xmurrix