Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Fragen zur Installation von CONTENIDO 4.10? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
Antworten
xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von xmurrix » Sa 30. Nov 2019, 00:29

Hallo zusammen,

kürzlich wurde ein Issue in GitHub bearbeitet, bei es es darum ging, dass CONTENIDO im Setup-Prozess Fehler erzeugt hat, wenn der Datenbank-Server mit dem SQL-Mode "NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION" lief. Datenbank-Felder vom Typ date, die die "NOT NULL" Einschränkung hatten, wurden auf CURRENT_TIMESTAMP umgestellt. Der Link zum Ticket ist wie folgt:
https://github.com/CONTENIDO/CONTENIDO/issues/22

Nun, im nachhinein ist mir aufgefallen, dass die Änderungen die Probleme im Setup zwar lösen, der jetzige Stand (Entwicklungsstand in der develop-Branch) aber andere Probleme nach sich zieht.

In Verbindung mit CURRENT_TIMESTAMP sehe ich Probleme in con_user.last_pw_request und in con_art_lang.published, Details dazu gibt es im folgenden GitHub-Issue:
https://github.com/CONTENIDO/CONTENIDO/issues/86

Es ist eine Diskussion, bei der Rat und Erfahrung anderer CONTENIDO-Entwickler gefragt ist, daher bitte ich euch, dabei mitzuwirken.

Danke und Grüße
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.

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von emergence » Mo 2. Dez 2019, 15:30

also wenn ich mir das so überlege, CURRENT_TIMESTAMP zu setzen, wo vorher 0000-00-00 00:00:00 war, ist ein fehler...
ich hätte als alternative empfohlen NULL setzbar zu machen bzw als default zu definieren, falls das datum nicht gesetzt bzw unbekannt ist..
zb bei published... oder wenn man eine art confirmed datum benötigt... da macht CURRENT_TIMESTAMP keinen sinn...
*** make your own tools (wishlist :: thx)

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von xmurrix » Mo 2. Dez 2019, 15:39

...also wenn ich mir das so überlege, CURRENT_TIMESTAMP zu setzen, wo vorher 0000-00-00 00:00:00 war, ist ein fehler...
Danke für das Feedback, mittlerweile sehe ich das auch so. Überall, wo man die "NOT NULL" Einschränkung entfernen kann, sollte man das machen. Nur dort, wo man keine NULL-Werte für Datum haben kann, sollte man sich entweder für CURRENT_TIMESTAMP entscheiden oder eine andere Alternative, wie z. B. '1970-01-01 00:00:00', überlegen.
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.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von Faar » Mo 2. Dez 2019, 16:34

emergence hat geschrieben:
Mo 2. Dez 2019, 15:30
also wenn ich mir das so überlege, CURRENT_TIMESTAMP zu setzen, wo vorher 0000-00-00 00:00:00 war, ist ein fehler...
Das sehe ich auch so, weil 0000-00-00 00:00:00 sagt klar, da wurde nichts eingetragen und der Standardwert gesetzt. Beim Timestamp steht etwas drin, ob richtig oder falsch.
Nur sagt der Strict_mode eben auch, dass 0000-00-00 00:00:00 eine Warnung ausgibt, die man jedoch umgehen kann, wenn man INSERT IGNORE oder UPDATE IGNORE ins SQL schreibt.
https://dev.mysql.com/doc/refman/5.7/en ... ro_in_date
ich hätte als alternative empfohlen NULL setzbar zu machen bzw als default zu definieren, falls das datum nicht gesetzt bzw unbekannt ist..
Ich weiß nicht mehr wo aber ich glaube mich erinnern zu können, dass Datetime Zellenformat kein NULL als Default haben sollte.
Irgendwo hatte ich mal einen Fehler dieser Art gefunden, kanns aber nicht mehr sagen, ob es wirklich hier war.
Nun, hier gibts auch paar Tipps dazu:
https://stackoverflow.com/questions/363 ... r-datetime
STRICT_TRANS_TABLES setzt eben auch NO_ZEOR_IN_DATE

Probleme macht das hier gerne bei langen Contenido SQLs mit Unterabfragen:
https://dev.mysql.com/doc/refman/5.7/en ... l_group_by
Da wurde gerne mal nicht ganz genau der SQL-Code ausgeschrieben und schon kommt ein Fehler.
Kann man leicht reparieren, wenn man sich die SQL genau anschaut und sieht, wo etwas verschlampert wurde.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von Faar » Mo 2. Dez 2019, 16:35

xmurrix hat geschrieben:
Mo 2. Dez 2019, 15:39
... sollte man sich entweder für CURRENT_TIMESTAMP entscheiden oder eine andere Alternative, wie z. B. '1970-01-01 00:00:00', überlegen.
Oder die SQL-Codes Anpassen auf INSERT IGNORE oder UPDATE IGNORE
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von emergence » Mo 2. Dez 2019, 17:10

also über kurz oder lang wird der STRICT MODE in sql der standard sein...

NO_ZERO_DATE
im prinzip gehts darum das bei einem nicht definierten datum nicht mehr 0000-00-00 00:00:00 gesetzt werden kann...
lt. doku
NO_ZERO_DATE is deprecated. NO_ZERO_DATE is not part of strict mode, but should be used in conjunction with strict mode and is enabled by default

wenn man ein nicht gesetztes datum braucht muss man halt NULL setzen... das geht ja ohne weiteres...
macht auch mehr sinn wie 1970-01-01 00:00:00

ob zeit angabe oder nicht ist ja mittels DATE und DATETIME definiert...

eine table definition mit DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' oder DATE NOT NULL DEFAULT '0000-00-00' ist eh schwachsinn...
läßt man die default setzung weg wird bei nicht gesetzten datum '0000-00-00 00:00:00' bzw '0000-00-00' retour geliefert...
in zukunft auch wenn man dies mittels IGNORE gesetzt hätte liefert das sql einem NULL retour...

eine anpassung nur im insert part reicht leider nicht... php parts die auf '0000-00-00 00:00:00' oder '0000-00-00' gibts leider auch zu genüge...

bleiben wir jetzt mal beim setup der sql tabellen...

dort wo kein datum möglich sein sollte (published oder confirmed)
DATETIME NULL oder DATE NULL
dort wo ein aktuelles datum gesetzt sein soll DATE NOT NULL DEFAULT CURRENT_TIMESTAMP oder DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP

man muss halt noch die php logik umbauen und bei wenn DATE und NULL == 0000-00-00 und DATETIME und NULL == 0000-00-00 00:00:00 interpretieren...

NO_ZERO_IN_DATE ist mir eher egal... das wäre sowieso ein komplett ungültiges datum... denke das man da hier gar nix berücksichtigen muss...
*** make your own tools (wishlist :: thx)

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von xmurrix » Di 3. Dez 2019, 11:11

Faar hat geschrieben:
Mo 2. Dez 2019, 16:35
...Oder die SQL-Codes Anpassen auf INSERT IGNORE oder UPDATE IGNORE...
Auch eine Möglichkeit. Laut Doku wird bei strict mode dann kein Fehler geworfen, sondern eine Warnung. Auch versucht MySQL die Werte anzupassen, bevor der Eintrag in der DB landet. Da sehe ich das Problem. Wir wissen nicht, was die DB dann für Werte einträgt.

Auch müssten wir alle Stellen anpassen, in denen SQL Statements erstellt werden, auch in den generischen DB-Klassen. Das führt zu einem unnötigen Mehraufwand im Code. Einfacher ist es, die NOT NULL Einschränkung zu entfernen, das wird für die meisten Datumfelder in der DB sehr gut funktionieren.
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.

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von xmurrix » Di 3. Dez 2019, 11:20

emergence hat geschrieben:
Mo 2. Dez 2019, 17:10
...man muss halt noch die php logik umbauen und bei wenn DATE und NULL == 0000-00-00 und DATETIME und NULL == 0000-00-00 00:00:00 interpretieren...
Soweit ich das sehen kann, wird im Code sowieso meist auf 0000-00-00 00:00:00 (respektive auf 0000-00-00) und NULL geprüft. Daher scheint das Entfernen der NOT NULL Einschränkung aus den Feldern vom Typ datetime die Lösung mit dem geringsten Aufwand und Bruch der Abwärtskompatibilität zu sein. Den Code in CONTENIDO können wir zwar anpassen, mit dieser Änderung sollten aber auch die meisten Module/Plugins anderer Entwickler ohne Änderungen funktionieren.
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.

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von xmurrix » Di 10. Dez 2019, 19:52

Hallo zusammen,

in der Branch "bug/#106-remove-default-value-current_timestamp-for-database-fields-of-type-datetime" wurde die überarbeitete Version der Datenbankfelder vom Typ "datetime" gepushed.

Der Link zur Branch ist:
https://github.com/CONTENIDO/CONTENIDO/ ... e-datetime

Die Änderungen sind folgende:
  • Datenbankfelder, die das Erstellungsdatum eines Datensatzes enthalten, haben die NOT NULL Einschränkung mit dem default Wert NOW(), z. B. `created` datetime NOT NULL default NOW()
  • Datenbankfelder, die das Änderungsdatum eines Datensatzes enthalten, können NULL Werte enthalten, z. B. `modified` datetime NULL
  • Datenbankfelder wie con_art_lang.published, con_frontendusers.valid_from, con_frontendusers.valid_to, con_user.last_pw_request, con_user.valid_to, con_user.valid_from, con_pi_news_rcp.confirmeddate, con_user_pw_request.request und con_user_pw_request.expiration, die nur unter bestimmtem Kriterien ein Datum haben sollen, können auch NULL Werte enthalten
  • Alle Bereiche, die mit Nullen befüllten Datumswerten ('0000-00-00 00:00:00') arbeiten, sind angepasst
  • SQL der Installation, der Beispielmodule und der Plugins ist angepasst
Die Installation von CONTENIDO läuft unter MySQL mit dem SQL Moduls "NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION" ohne Probleme durch.

Als nächstes werde ich mir das Upgrade eine vorhandenen CONTENIDO Installation ansehen. Hier rechne ich mit Problemen, da wir dann in der Datenbank Einträge mit '0000-00-00 00:00:00' haben können. Das Setup sollte um die Funktion erweitert werden, solche Einträge zu finden und diese eventuell anzupassen.

Euch bitte ich darum, die Änderungen anzusehen und, falls ihr die Zeit dazu aufbringen könnt, diese bei euch testen. Feedback könnt ihr auch im pull-Request unter folgender URL geben:
https://github.com/CONTENIDO/CONTENIDO/pull/115

Wichtig:
Da wir von mit Nullen befüllten Datumswerten weggehen, weil MySQL immer mehr strikter wird, sind diese Änderungen nicht abwärtskompatibel mit Modulen und Plugins, die Prüfungen auf Datumswerte mit '0000-00-00 00:00:00' oder '' machen. Nach einem Setup müssten Admins/Entwickler sich Module & Pluins ansehen, die mit Datumswerten arbeiten.

Grüße
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.

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von xmurrix » Di 7. Jun 2022, 14:35

Hallo zusammen,

ältere MySQL-Versionen kennen default-Werte wie CURRENT_TIMESTAMP oder NOW() oder ähnliches für Felder vom Typ datetime nicht.

Bei einer frischen CONTENIDO-Installation auf einer MariaDB 5.5 gab es viele Fehlermeldungen wie folgt:

Code: Alles auswählen

Warning: "Database failure: 1067 (Invalid default value for 'logtimestamp') - /setup/index.php?c=db ALTER TABLE `con_actionlog` ADD COLUMN `logtimestamp` datetime NULL DEFAULT CURRENT_TIMESTAMP 
Das ist erst seit MySQL 5.6.5 möglich.

Der aktuelle Entwicklungsstand von CONTENIDO kann somit nicht auf einem System mit MySQL < 5.6.5 installiert werden.
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.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von Faar » Di 7. Jun 2022, 14:54

xmurrix hat geschrieben:
Di 7. Jun 2022, 14:35
Der aktuelle Entwicklungsstand von CONTENIDO kann somit nicht auf einem System mit MySQL < 5.6.5 installiert werden.
Ich finde das vertretbar, weil kaum einer eine DB mehr mit MySQL < 5.7.x anbietet.
PHP gib's ja auch nicht mehr mit 5.4 im Angebot.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von xmurrix » Di 7. Jun 2022, 15:26

...Ich finde das vertretbar, weil kaum einer eine DB mehr mit MySQL < 5.7.x anbietet...
Ich habe ein Ticket dazu erstellt und das sehe ich auch so.

Wir haben einen Fall in der Community, bei dem auf dem Server ältere CONTENIDO-Installationen mit MySQL < 5.6.5 laufen. Daher schlägt die Installation des aktuellen Entwicklungsstandes fehl. Es ist auch nicht klar, ob man auf dem Server zwei verschiedene DB-Server betreiben kann, da das vom Provider verwaltet wird.

Wenn wir die Voraussetzungen für CONTENIDO auf MySQL 5.7 hochschrauben, sollten wir das beim Setup prüfen und dem Benutzer eine entsprechende Meldung geben.
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.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Bitte um eure Meinung zu einem CONTENIDO GitGub Issue

Beitrag von Faar » Di 7. Jun 2022, 15:43

xmurrix hat geschrieben:
Di 7. Jun 2022, 15:26
Wir haben einen Fall in der Community, bei dem auf dem Server ältere CONTENIDO-Installationen mit MySQL < 5.6.5 laufen.
Daher schlägt die Installation des aktuellen Entwicklungsstandes fehl. Es ist auch nicht klar, ob man auf dem Server zwei verschiedene DB-Server betreiben kann, da das vom Provider verwaltet wird.
Der einfachste Fall wäre es, wenn man die Daten der DB exportiert und in eine neue DB importiert und fertig ist.
Es gibt Provider, die z.B. Reseller sind und nicht alle Möglichkeiten eines vollwertigen Hosters anbieten können, wie z.B. DBs per Mausklick.
Zumindest MariaDB kann current_timestamp und now auch: https://mariadb.com/kb/en/current_timestamp/
Wäre also eine Ausweichmöglichkeit.
Wenn wir die Voraussetzungen für CONTENIDO auf MySQL 5.7 hochschrauben, sollten wir das beim Setup prüfen und dem Benutzer eine entsprechende Meldung geben.
Ja.
Und in der Doku.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

Antworten