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
Diskussion: CONTENIDO Update mit striktem SQL Modus
Diskussion: CONTENIDO Update mit striktem SQL Modus
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.
Re: Diskussion: CONTENIDO Update mit striktem SQL Modus
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?
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?
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.
Re: Diskussion: CONTENIDO Update mit striktem SQL Modus
Hallo Faar,
danke für dein Feedback.
Gruß
xmurrix
danke für dein Feedback.
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"....Was macht man, wenn das Datum aber 1000-01-01 00:00:00 gesetzt wäre?...
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....Die Idee, für die Installation den Strictmode auszusetzen, die ist die pragmatischste, löst aber das Problem nicht auf Dauer...
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....Probleme kriegen eher die, die gleich damit rechnen ohne zu prüfen, was da drin steht...
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....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?...
Gruß
xmurrix
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.