Avatar

Update des Forums (German / Deutsch)

by Micha ⌂, Thursday, July 18, 2019, 19:07 (31 days ago)

Hi,

ich wollte gerade ein Testforum updaten, welches ich länger nicht gepflegt hatte. Dabei sind mir zwei Sachen aufgefallen:

Zunächst habe ich das Update-Script update_2.3.5-2.4.php verwendet. Anschließend wollte ich dann mit update_2.4.19.1-2.5.php auf die Pre-Version von 2.5. Das ging schief, weil die Version bereits auf der Pre-Version nach dem ersten update stand. Folglich sind die Änderungen für den 2.5er Zweig nicht durchgeführt worden. Ich habe dann händisch alle SQLs rausgesucht und wollte die neuen/geänderten Tabellen nachziehen. Das hat bis auf eine Tabelle auch funktioniert. Beim folgendem Update gehts bei mir aber wieder schief:

ALTER TABLE `mlf2_tags` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci

MySQL bricht mit folgender Meldung ab:

#1709 - Index column size too large. The maximum column size is 767 bytes.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Friday, July 19, 2019, 07:40 (30 days ago) @ Micha

Hallo

Zunächst habe ich das Update-Script update_2.3.5-2.4.php verwendet. Anschließend wollte ich dann mit update_2.4.19.1-2.5.php auf die Pre-Version von 2.5. Das ging schief, weil die Version bereits auf der Pre-Version nach dem ersten update stand.

Komisch, im Updateskript finde ich nichts, was das verursachen könnte. Das, zumal die Versionsnummer aus config/VERSION übernommen wird.

Folglich sind die Änderungen für den 2.5er Zweig nicht durchgeführt worden. Ich habe dann händisch alle SQLs rausgesucht und wollte die neuen/geänderten Tabellen nachziehen. Das hat bis auf eine Tabelle auch funktioniert. Beim folgendem Update gehts bei mir aber wieder schief:

ALTER TABLE `mlf2_tags` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci

MySQL bricht mit folgender Meldung ab:

#1709 - Index column size too large. The maximum column size is 767 bytes.

Dass es diese Einschränkung bei der Indexgröße gibt, war mir bewusst (Abschnitt 3. unerwartete Einschränkungen). Von dort:

„Zudem beträgt die Länge eines Indexes für Tabellen vom Typ InnoDB bis MySQL 5.7 nur 768 Byte. Das entspricht nur der dreifachen Länge von varchar(256) und könnte im Zweifelsfall ein voll ausgenutztes Feld nicht im Index abbilden, wenn der Inhalt nur aus 4-bytigen UTF-8-Zeichen bestünde.“

Dass die Abfrage deshalb abgebrochen wird, ist mir bisher noch nicht begegnet. Das liegt vermutlich an der MySQL-Serverkonfiguration, denn bei mir ging die selbe Abfrage durch. Ich habe allerdings noch keine Meinung zum Umgang mit dem Problem. Lösen müssen wir es, da das Skript $irgendwo installiert werden kann und wir voraussetzen müssen, keine Kenntnis von der Konfiguration von $irgendwo zu haben. Den Index auf dem Textfeld, dass den Tag als solches enthält, brauchen wir. Ausgehend von der deutschen Sprache würde ich bezweifeln wollen, dass wir die gegenwärtige Feldlänge von 255 brauchen, aber ich habe absolut keine Ahnung, wie das in anderen Sprachen aussieht.

[edit]
Ich habe aktuell keine Möglichkeit, auf eine MySQL-Installation zuzugreifen. Ausgehend von der Indexlänge von 768 Byte beträgt die maximal abbildbare Feldlänge, wenn ich es richtig verstehe, 192 Zeichen (768/4). Es wäre also einen Versuch wert, die Feldlänge auf 192 Zeichen zu begrenzen und danach die Änderung des Charsets auszuprobieren.

ALTER TABLE mlf2_tags CHANGE tag tag VARCHAR(192) NOT NULL;
ALTER TABLE mlf2_tags CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

[/edit]

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Friday, July 19, 2019, 08:40 (30 days ago) @ Auge

Hi Auge,

Komisch

Ja, vielleicht habe ich auch was missverstanden. Ich kann es jetzt nicht mehr reproduzieren. Ich hatte erst versucht direkt mit dem Script auf 2.5 zu gehen, dass ging nicht, weil meine Version zu alt war. Anschließend habe ich das 2.4er Script genutzt und wollte dann den letzten Schritt mit dem 2.5er Script machen. Das hat er dann verweigert, weil meine Version bereits 2.4.99.1 wäre. Dieser Wert stand dann auch in der DB aber die Tabellen bspw. B8 wurden nicht angelegt, sodass das Update nicht funktioniert hat.

Dass es diese Einschränkung bei der Indexgröße gibt, war mir bewusst (Abschnitt 3. unerwartete Einschränkungen).

Das habe ich gelöst, indem ich den ROW_FORMAT auf DYNAMISCH gesetzt habe (stand auf COMPACT). Nach dem Update konnte ich auch wieder auf COMPACT zurückstellen.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Friday, July 19, 2019, 08:47 (30 days ago) @ Micha

Hallo

Dass es diese Einschränkung bei der Indexgröße gibt, war mir bewusst (Abschnitt 3. unerwartete Einschränkungen).


Das habe ich gelöst, indem ich den ROW_FORMAT auf DYNAMISCH gesetzt habe (stand auf COMPACT). Nach dem Update konnte ich auch wieder auf COMPACT zurückstellen.

Kannst du zu ROW_FORMAT für die Nachwelt bitte etwas ausführen?

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Friday, July 19, 2019, 09:00 (30 days ago) @ Auge

Hi,

da ich nicht sicher sagen kann, ob das _immer_ so funktioniert oder einfach nur Glück war, belasse ich es mal bei einem Screenshot aus PHPMyAdmin

[image]

Ich hatte das beim Suche nach dem Fehler auch irgendwo gelesen, finde es aber nicht mehr.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Friday, July 19, 2019, 11:43 (30 days ago) @ Micha

Hallo

da ich nicht sicher sagen kann, ob das _immer_ so funktioniert oder einfach nur Glück war, belasse ich es mal bei einem Screenshot

Ich hatte das beim Suche nach dem Fehler auch irgendwo gelesen, finde es aber nicht mehr.

Ich habe mittlerweile selbst Zeit gefunden, zu suchen. ROW_FORMAT = DYNAMIC wird als ein Weg vorgeschlagen, das Problem zu lösen [1]. Ein anderer Vorschlag ist es, die MySQL-Konfigurationsdatei mit innodb_large_prefix = 1 beziehungsweise als Abfrage mit SET GLOBAL innodb_large_prefix = `ON` in Kombination mit set SET GLOBAL innodb_file_format = BARRACUDA anzupassen, womit ein Index bis zu 3072 Bytes groß werden kann. Dieser Weg fällt für uns aus, da die Forenbetreiber wohl nur in Ausnahmen Zugriff auf die Serverkonfiguration haben dürften (sowohl auf die Datei als auch in Sachen Datenbankrechte).

In diesem Stack-Overflow-Thread ist für mich die aktuell letzte Antwort, beginnend mit "This is an XY problem" interessant. Der Autor beleuchtet das Problem von einer anderen Seite, nach der sich die bei dir angegebene Fehlermeldung auf ein Symptom bezieht und nicht auf die Ursache.

Danach ist das Problem, dass der UNIQUE-Index die Vermeidung doppelter Einträge sicherstellen soll und die Feldgröße unterschiedlich lange Einträge ermöglicht, von denen die längsten die maximal mögliche Größe eines Index-Eintrags sprengen können.

Der Vorschlag ist nun, für jeden Eintrag einen Hash (der Autor schlägt SHA256 vor) mitzuführen. Ein Hash hat immer die gleiche Länge. Ein Hash braucht keinen Charset utf8mb4, er braucht nicht einmal utf8, denn er besteht nur aus ASCII-Zeichen, die, so schlägt der Autor vor, per UNHEX als 32-Bit-Bynary-Feld gespeichert werden sollen. Ein Index auf das Hash-Feld kann die maximale Größe des Index-Eintrags nicht sprengen, womit sich das Ausgangsproblem in Wohlgefallen auflöst.

In seinem Beispiel geht es um E-Mail-Adressen, die zur Speicherung mit UNHEX(SHA2(email, 256)) behandelt werden.

- UNHEX: MySQL-Doku, eingeführt: ?, laut Doku verfügbar mit MySQL 5.5
- SHA2: MySQL-Doku, eingeführt: ?, laut Doku verfügbar mit MySQL 5.5, Achtung: "This function works only if MySQL has been configured with SSL support." Keine Ahnung, ob wir das voraussetzen können.

Da wir den Wert des Tags nicht kryptografisch verschleiern wollen – er steht schließlich im Klartext eine Spalte "neben" dem Hash –, könnte auch SHA1 reichen. Allerdings wurden für SHA1 schon Kollisionen (verschiedene Zeichenketten, für die mit SHA1 der selbe Hash errechnet wird) nachgewiesen.

Ob diese Lösung für uns überhaupt gangbar ist, müssen wir testen.

Tschö, Auge

[1]: Github, Gitea-Issue zur Fehlermeldung 1709; Stack-Overflow-Thread zur Fehlermeldung 1709

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Saturday, July 27, 2019, 18:52 (22 days ago) @ Auge

Hallo,

Ob diese Lösung für uns überhaupt gangbar ist, müssen wir testen.

Ich denke, wir sollten schlicht die Feldgröße reduzieren. Es geht hier um einen einzigen Tag. Benötigt der wirklich 255 Zeichen? Reichen nicht auch 150 oder 100 aus? Ich kann nicht erkennen, warum wir hier extra eine neue Spalte hinzufügen sollen für ein einfaches Feature.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Monday, July 29, 2019, 08:34 (20 days ago) @ Micha

Hallo Micha,

Ob diese Lösung für uns überhaupt gangbar ist, müssen wir testen.


Ich denke, wir sollten schlicht die Feldgröße reduzieren. Es geht hier um einen einzigen Tag. Benötigt der wirklich 255 Zeichen? Reichen nicht auch 150 oder 100 aus?

In unserem und unserem verwandten Sprach- und Schriftsystemen sollte eine Feldlänge von 100 Zeichen für einen Tag mehr als ausreichend sein. Die sprengt man wohl am ehesten in der deutschen Sprache mit seinen Komposita und wenn, dann mutwillig.

Ich kann nicht erkennen, warum wir hier extra eine neue Spalte hinzufügen sollen für ein einfaches Feature.

Es ist die Lösung, die mir, abseits des Aufwands der zusätzlichen Spalte und der Erstellung der Hashes, am konsequentesten erscheint und vor meiner Beschreibung noch nicht erwähnt wurde. Ob es in unserem Fall notwendig ist, diesen Lösungsweg zu beschreiten, habe ich ja selbst infrage gestellt. Denn wenn wir das für die Tag-Tabelle umsetzen würden, fänden sich bestimmt auch noch obligatorische drei weitere Stellen, die dem System folgen sollten und somit geändert werden müssten.

Mit einer kleineren/kürzeren Spalte umgehen wir das Problem wohl auf die einfachste Weise.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Monday, July 29, 2019, 08:43 (20 days ago) @ Auge

Hallo Auge,

Danke für Deine Rückmeldung und Bestätigung.

Mit einer kleineren/kürzeren Spalte umgehen wir das Problem wohl auf die einfachste Weise.

Ja, das denke ich auch. Soll ich die Änderung einpflegen oder willst Du dies übernehmen? Wir sollten dies afaik auch rückwirkend für die 2.4.99.1 noch übernehmen.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Monday, July 29, 2019, 09:55 (20 days ago) @ Micha

Hallo micha,

Danke für Deine Rückmeldung und Bestätigung.

Büdde

Mit einer kleineren/kürzeren Spalte umgehen wir das Problem wohl auf die einfachste Weise.


Ja, das denke ich auch. Soll ich die Änderung einpflegen oder willst Du dies übernehmen?

Mach' ich heute noch.

Wir sollten dies afaik auch rückwirkend für die 2.4.99.1 noch übernehmen.

Brauchen wir nicht. Wenn die Änderung drin ist und sich das Forum installieren und auch aktualisieren lässt, baue ich eine neue Version. Mein PR wird da nicht drin sein, da ich in den letzten Wochen so gut wie nicht dran arbeiten konnte. Eine neue Version werden wir aber schon deshalb brauchen, weil deine vielen Änderungen der letzten Wochen getestet werden wollen statt brach zu liegen. :-)

An der Stelle von mir ein Dankeschön für deine Arbeit an Details, die teilweise unscheinbar aussehen, aber dennoch wichtig sind.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Monday, July 29, 2019, 10:39 (20 days ago) @ Auge

Hi,

Mach' ich heute noch.

Super!

Dankeschön für deine Arbeit

Kein Ding.


Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Micha ⌂, Saturday, July 20, 2019, 12:10 (29 days ago) @ Micha

Hallo,

ich habe heute ein weiteres Forum auf die pre-2.5 versucht zu updaten. Im Prinzip mit dem selben Ergebnis. Das Update wird mit der genannten SQL-Fehlermeldung abgebrochen. Diese habe ich, wie schon gezeigt, entsprechend behoben. Das hat also erneut funktioniert.

Dennoch habe ich ein weiteres Problem mit dem Updatescript gefunden, dass mich vor ein paar Tagen mutmaßen lies, es läge an den Files update_2.3.5-2.4.php und update_2.4.19.1-2.5.php. Das Problem ist, dass zwar geprüft wird, ob die Datei /config/db_settings.phpvorhanden und beschreibbar ist aber es kein else-Zweig gibt. Wenn also diese Datei dort nicht liegt oder man keine Schreibrechte hat, dann wird der ganze Rest zwar aktualisiert aber Teile fehlen schlicht, weil diese übersprungen wurden.

Ich habe ein else-Zweig mal ergänzt, sodass das Script dort abbrechen würde. Zur Info: Meine configs liegen außerhalb von htdocs.

/Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Thursday, August 08, 2019, 14:10 (10 days ago) @ Micha

Hallo Micha

Ich habe endlich die notwendigen Änderungen zusammengeführt und eine neue Version zusammengebaut. Bei mir kann ich die neue Version sowohl installieren als auch von der Version 2.4.20 aus aktualisieren.

Da ich aber einen gnädigen SQL-Server habe, der bestimmte Fehler übergeht, kann ich nicht testen, was deinen Server beim Update aus dem Tritt gebracht hat. Deshalb habe ich, sowohl auf Github als auch hier, noch keine Ankündigung einer neuen Version veröffentlicht. Ich bitte dich, den aktuellen Stand des Master-Branches (2019-08-08 15:58 MESZ, Commit eb24c33d49ac), der alle notwendigen Änderungen inklusive derer für eine neue Version beinhalten sollte, sowohl zu installieren als auch ein Update auszuführen und Rückmeldung zu geben.

Wenn das alles passt (kann installiert und aktualisiert werden) werde ich am Sonntag oder Montag den Tag erstellen und die Verion fertig machen.

Danke und tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Thursday, August 15, 2019, 19:42 (3 days ago) @ Auge

Hi,

ich starte mit einer frischen (und erfolgreichen) Installation von 2.3.5 (die sich jedoch als 2.3.5 RC selbst bezeichnet). Von dort aus sollte man ja, so verstehe ich unsere Doku, problemlos zu jeder höheren Version kommen.

Wenn ich versuche, die update_2.3.5-2.4.php auszuführen, klappt diese nicht:
Error in line 365: This update file doesn't work with the current version.

Um fortzufahren, half ich mir mit einem

UPDATE `mlf2_test_settings` SET `value`='2.3.5' WHERE `name`= 'version'

Das sollten wir irgendwie mal angehen, oder habe ich tatsächlich das falsche 2.3.5 verwendet?

Das Update wird nun nicht vorzeitig beendet und ich erhalte die interessante Meldung:
Bitte jetzt die folgenden Dateien/Verzeichnisse der neuen Version (2.4.99.2) hochladen:. Man beachte die Version. Auch in der neuen Tabelle mlf2_test_temp_infos steht nun 2.4.99.2. Der Versuch, nun auf 2.4.99.2 mittels der Datei update_2.4.19.1-2.5.php zu gelangen, scheitert erwartungsgemäß mit:
Error in line 183: This update file doesn't work with the current version.

Wenn wir das nicht durch eine entsprechende Implementierung beheben, dann schlage ich vor, dass nur noch eine einzige update-Datei im Downloadpaket liegen darf. In der jetzigen Form funktioniert dies nicht. Ich breche an dieser Stelle ab und starte erneut mit 2.4.20 als Basis.

Auch dieses Update schlägt fehlt.
Database error in line 349: Index column size too large. The maximum column size is 767 bytes. Für die Tags habe ich gesehen, dass Du

CHANGE `tag` `tag` VARCHAR(128)

hinzugefügt hast. Für die Namen (oder besser alle VARCHARs) müsste dies wohl analog getan werden, wenn diese einen Index haben. Bitte beachte, dass die Änderung auf 128 Zeichen nicht durchgeführt wird, wenn man 2.4.99.1 irgendwie zum Laufen gebracht hat. Das sollte mMn. noch behoben werden.
Was passiert, wenn es einen Namen gab, der bereits länger als 128 Zeichen war? Wird der dann mit dem Change direkt abgeschnitten oder wird das Update dann nicht mehr durchgeführt?

Ich starte erneut mit Version 2.4.20 als Basis, wobei ich Zeile 316 ändere in

 if(!@mysqli_query($connid, "ALTER TABLE `" . $db_settings['userdata_table'] . "` CHANGE `user_name` `user_name` VARCHAR(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT '';")) {

damit wird das Update durchgeführt, d.h.

Bitte jetzt die folgenden Dateien/Verzeichnisse der neuen Version (2.4.99.2) hochladen:

[Datei]config/b8_config.php
[Datei]config/php_mailer.php
[Datei]index.php
[Datei]js/admin.js
[Datei]js/admin.min.js
[Datei]js/posting.js
[Datei]js/posting.min.js
[Ordner]includes
[Ordner]lang
[Ordner]modules/b8
[Ordner]modules/phpmailer
[Ordner]themes/default

(hier könnte man js als Order wohl nehmen ums zu vereinfachen)

Die Probleme, die mit B8 kommuniziert wurden, kann ich nicht bestätigen. Ich kann als unregistrierter Nutzer schreiben und antworten, und erhaltet keine Fehlermeldung. Auch die DB-Tabellen werden gefüllt.

Eine frische Installation probiere ich morgen aus.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Friday, August 16, 2019, 08:00 (2 days ago) @ Micha

Hallo

ich starte mit einer frischen (und erfolgreichen) Installation von 2.3.5 (die sich jedoch als 2.3.5 RC selbst bezeichnet). Von dort aus sollte man ja, so verstehe ich unsere Doku, problemlos zu jeder höheren Version kommen.

Wenn ich versuche, die update_2.3.5-2.4.php auszuführen, klappt diese nicht:
Error in line 365: This update file doesn't work with the current version.

Um fortzufahren, half ich mir mit einem

UPDATE `mlf2_test_settings` SET `value`='2.3.5' WHERE `name`= 'version'

Das sollten wir irgendwie mal angehen, oder habe ich tatsächlich das falsche 2.3.5 verwendet?

Ich vermute letzteres, obwohl mir bis eben nicht einmal klar war, dass es von der 2.3.5 einen RC gegeben hat. Das ist ja nun auch schon wieder über drei Jahre her.

In der Release-Historie ist von einer solchen Version jedenfalls nichts zu sehen. In der update_2.3.5-2.4.php, die ab der Version 2.3.99.2 benutzt wurde (die folgenden Links führen zu diesem Versionsstand), wird die Version 2.3.5 RC jedoch tatsächlich erwähnt. In den Bedingungen für die einzelnen Schritte wird Version "2.3.5 RC" ebenfalls aufgelistet (Beispiel in Zeile #147). Die Version wird aber im Array $update['version'], welches bestimmt, welche Versionen als Ausgangspunkt des Updates dienen können, nicht aufgelistet.

Das dürfte die Ursache für den Abbruch deines Updates sein. Da außer dir und Alex wohl niemand je den 2.3.5-er RC im einsatz hatte, ist das nie aufgefallen. Zumal dann, wenn die wenigen potentiell Betroffenen, die als Ausnahme meine Annahme bestätigen würden, sich hoffentlich sklavisch an "from version 2.3.5 upwards" (ganz ohne RC) gehalten haben dürften.

Das Update wird nun nicht vorzeitig beendet und ich erhalte die interessante Meldung:
Bitte jetzt die folgenden Dateien/Verzeichnisse der neuen Version (2.4.99.2) hochladen:. Man beachte die Version. Auch in der neuen Tabelle mlf2_test_temp_infos steht nun 2.4.99.2. Der Versuch, nun auf 2.4.99.2 mittels der Datei update_2.4.19.1-2.5.php zu gelangen, scheitert erwartungsgemäß mit:
Error in line 183: This update file doesn't work with the current version.

Das ist sehr komisch. Schon allein der Umstand, dass die Versionsnummer in der Tabelle mlf2_test_temp_infos steht, spricht dafür, dass du ein Update auf mindestens Version 2.4.19 erfolgt ist. Die kannst du nur mit der update_2.3.5-2.4.php durchführen, wir prüfen aber offensichtlich nicht, ob die Zielversion (laut config/VERSION) vom Skript überhaupt abgedeckt ist.

Hier der Code aus der update_2.3.5-2.4.php (Stand: 2.4.20, ab Zeile #365).

// check version:
if(!file_exists('config/VERSION')) {
 $update['errors'][] = 'Error in line '.__LINE__.': Missing the file config/VERSION. Load it up from your script package (config/VERSION) before proceeding.';
}
if (empty($update['errors'])) {
 $newVersion = trim(file_get_contents('config/VERSION'));
 if (compare_versions(array('old' => $settings['version'], 'new' => $newVersion)) !== true) {
 #if ($newVersion <= $settings['version']) {
  $update['errors'][] = 'Error in line '.__LINE__.': The version you want to install (see string in config/VERSION) must be greater than the current installed version. Current version: '. htmlspecialchars($settings['version']) .', version you want to install: '.  htmlspecialchars($newVersion) .'. Please check also if you uploaded the actual file version of config/VERSION. Search therefore for the file date and compare it with the date from the installation package.';
 }
 if(!in_array($settings['version'], $update['version'])) {
  $update['errors'][] = 'Error in line '.__LINE__.': This update file doesn\'t work with the current version.';
 }
}

Die Prüfung erfolgt auf folgendes:

- Ist die Datei config/VERSION vorhanden?
- Ist die Zielversion laut config/VERSION größer als die Ausgangsversion?
- Ist die Ausgangsversion im Array $update['version'] enthalten, also behandelbar?

Was tatsächlich nicht geprüft wird, ist die Frage, ob die Zielversion durch das Skript abgedeckt ist. Wenn du also aus Versehen die config/VERSION der 2.4.99.2 hochgeladen hattest, wird zwar das Forum auf den Stand von Version 2.4.20 (oder was auch immer) gebracht, als Versionsnummer wird aber die Angabe aus config/VERSION benutzt, also eine falsche Angabe eingetragen.

Das ist das einzige für mich denkbare Szenario, wie soetwas passieren kann.

Wenn wir das nicht durch eine entsprechende Implementierung beheben, dann schlage ich vor, dass nur noch eine einzige update-Datei im Downloadpaket liegen darf. In der jetzigen Form funktioniert dies nicht. Ich breche an dieser Stelle ab und starte erneut mit 2.4.20 als Basis.

Dass jetzt noch zwei Skripte vorhanden sind, ist meiner Schludrigkeit zu verdanken. Ich weiß ja, dass ich die update_2.3.5-2.4.php nicht mehr benutzen darf und zu ignorieren habe. Darüber, dass das andere ins schleudern bringt, habe ich nicht nachgedacht.

Auch dieses Update schlägt fehlt.
Database error in line 349: Index column size too large. The maximum column size is 767 bytes. ... Für die Namen (oder besser alle VARCHARs) müsste dies wohl analog getan werden, wenn diese einen Index haben.

Ich habe schon befürchtet, dass ich andere Stellen, die dieses Problem ebenfalls heraufbeschwören, übersehen haben könnte. :-(

Bitte beachte, dass die Änderung auf 128 Zeichen nicht durchgeführt wird, wenn man 2.4.99.1 irgendwie zum Laufen gebracht hat. Das sollte mMn. noch behoben werden.

Sprichst du über die Änderung der Tabelle für Tags?

Was passiert, wenn es einen Namen gab, der bereits länger als 128 Zeichen war? Wird der dann mit dem Change direkt abgeschnitten oder wird das Update dann nicht mehr durchgeführt?

Das habe ich noch nicht probiert, ich befürchte aber, dass der ALTER-Query dann abhängig von der SQL-Server-Konfiguration abgebrochen wird. Die Charset-Änderung ist bei mir ja durchgelaufen und bei dir nicht.

Ich starte erneut mit Version 2.4.20 als Basis, wobei ich Zeile 316 ändere in

 if(!@mysqli_query($connid, "ALTER TABLE `" . $db_settings['userdata_table'] . "` CHANGE `user_name` `user_name` VARCHAR(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT '';")) {

damit wird das Update durchgeführt

Das heißt dann wohl, dass mlf2_userdata.user_name die einzige weitere Spalte ist, die von dem Problem betroffen ist. Bleibt die Frage nach bereits eingetragenen Namen, die länger als 128 Zeichen sind und damit das Update verhindern.

Bitte jetzt die folgenden Dateien/Verzeichnisse der neuen Version (2.4.99.2) hochladen:

...
[Datei]js/admin.js
[Datei]js/admin.min.js
[Datei]js/posting.js
[Datei]js/posting.min.js
...

(hier könnte man js als Order wohl nehmen ums zu vereinfachen)

Da hast du recht.

Die Probleme, die mit B8 kommuniziert wurden, kann ich nicht bestätigen. Ich kann als unregistrierter Nutzer schreiben und antworten, und erhaltet keine Fehlermeldung. Auch die DB-Tabellen werden gefüllt.

Mich hat das auch gewundert. Hat Taurec eventuell doch den Upload irgend eines Skripts vergessen? :confused:

Eine frische Installation probiere ich morgen aus.

Danke. War doch gut, dass ich die Veröffentlichung der neuen Version hinausgezögert habe. :lookaround:

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Friday, August 16, 2019, 09:07 (1 day, 23 hours, 50 min. ago) @ Auge

Hallo,

Die Version wird aber im Array $update['version'], welches bestimmt, welche Versionen als Ausgangspunkt des Updates dienen können, nicht aufgelistet.

Ja. Das wird die Ursache sein. Möglicherweise ist auch einfach vergessen worden, dass RC wieder zu entfernen. Wie dem auch sei. Von dort kommt man nicht mehr weg. ;-)

Die Prüfung erfolgt auf folgendes:

- Ist die Datei config/VERSION vorhanden?
- Ist die Zielversion laut config/VERSION größer als die Ausgangsversion?
- Ist die Ausgangsversion im Array $update['version'] enthalten, also behandelbar?

Was tatsächlich nicht geprüft wird, ist die Frage, ob die Zielversion durch das Skript abgedeckt ist.

Genau. Ein Nutzer soll die Datei VERSION hochladen, die im config-Verzeichnis zu finden ist. Lädt er nun die aktuelle Version herunter, wird er auch exakt die im Downloadverzeichnis befindliche VERSION nehmen und keine andere/modifizierte. Er wird, wie ich, in dieses Problem laufen. Problematisch ist, dass er das nicht bemerkt. Er hat dann, wie Du schon sagst, 2.4.20 (oder was auch immer) installiert, das Forum gibt sich aber als 2.4.99.1 aus. Noch läuft alles einwandfrei aber ein Update auf 2.4.99.2 wird schief gehen, da die Dateien und die Datenbank nicht auf dem notwendigen Stand (2.4.99.1) sind, die vorausgesetzt werden für das Update. Hier sollten wir in jedem Fall handeln.

Ich habe schon befürchtet, dass ich andere Stellen, die dieses Problem ebenfalls heraufbeschwören, übersehen haben könnte. :-(

Ich will das heute (oder am Wochenende) noch auf einem anderen Server testen und werde berichten. Gegenwärtig ist es die einzige Problemstelle, ja.

Bitte beachte, dass die Änderung auf 128 Zeichen nicht durchgeführt wird, wenn man 2.4.99.1 irgendwie zum Laufen gebracht hat. Das sollte mMn. noch behoben werden.


Sprichst du über die Änderung der Tabelle für Tags?

Was ich meinte ist. Ich habe mein Forum bereits auf Version 2.4.99.1 geupdatet. Ich benötige also nur noch die Änderungen an der Datenbank, die in Version 2.4.99.2 hinzugekommen sind. Die Begrenzung der Felder auf 128 Zeichen würde ich nicht mitbekommen. Ich denke, die CHANGE-Statements müssten in beide if-Bedingungen. Sie werden dann im zweifel doppelt ausgeführt aber besser als gar nicht.

Ich möchte an dieser Stelle erneut anmerken, dass ich äußerst unzufrieden mit der gegenwärtigen Versionierung bin. Ich sehe nach wie vor keinen Vorteil oder Mehrwert aber durch x Dateien, RC, Sub- und Subsubversionen nur Probleme. Wir sollten hierüber ab Version 2.5 noch mal sprechen - finde ich.

Das habe ich noch nicht probiert, ich befürchte aber, dass der ALTER-Query dann abhängig von der SQL-Server-Konfiguration abgebrochen wird.

Das wäre unglücklich und auch eines der Probleme, die ich in unserem Updatescript ausgemacht habe. Wenn das Update schief geht an einer Stelle, dann hat man so eine Zwischenversion, von der man nicht mehr weg kommt. Selbst wenn man das SQL-Statement korrigiert im Script, lässt sich dieses nicht erneut aufrufen, da bereits ein Teil des Updates durchgeführt wurde. Wir benötigen hier ein Rollback oder etwas ähnliches. Ich in meiner Applikation mache es recht simple. Ich erzeuge für jeden SQL eine Subversion z.B. 20180106.0101 (Hauptversion ist das Datum hier 2018-01-06). Beim Update durchlaufe ich die diese Liste und prüfe, welche der Versionen größer ist als die bisherige und führe den SQL aus. Anschließend schreibe ich diese Subversion auch in die Datenbank. Sollte an einer Stelle ein SQL korrupt sein und das Update abbrechen, dann sehe ich, bei welchem SQL dies passiert ist und kann genau dort wieder einsteigen.

Dadurch, dass ich jedes SQL-Statement mit einer eigenen Version belege, muss ich auch nicht mehr zwischen Installation oder Update unterscheiden. Bei einer Installation durchläuft das Script einfach alle Einträge, beim Update nur die letzten/benötigten.

Das heißt dann wohl, dass mlf2_userdata.user_name die einzige weitere Spalte ist, die von dem Problem betroffen ist.

Wenn Du mich so festnagelst relativiere ich die Aussage: Das heißt also, dass mit user_name mindestens noch ein weiteres Feld existiert, dass Probleme macht. ;-)

Bleibt die Frage nach bereits eingetragenen Namen, die länger als 128 Zeichen sind und damit das Update verhindern.

Substr() könnten wir nutzen aber dann erzeugen wir u.U. Kollisionen. Der Name muss in jedem Fall nicht Unique sein, wie es aussieht. Aber auch hier stellt sich die Frage, wer hat schon einen Namen mit mehr als 50 Zeichen?

Mich hat das auch gewundert. Hat Taurec eventuell doch den Upload irgend eines Skripts vergessen? :confused:

Möglich. Er hat aber auch gesagt, dass es mit einer frischen Installation nicht ging. Das würde sich dann (fast) ausschließen, oder?

Alles weitere dann später
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums

by Auge ⌂ @, Friday, August 16, 2019, 10:27 (1 day, 22 hours, 30 min. ago) @ Micha

Hallo

Die Version wird aber im Array $update['version'], welches bestimmt, welche Versionen als Ausgangspunkt des Updates dienen können, nicht aufgelistet.


Ja. Das wird die Ursache sein. Möglicherweise ist auch einfach vergessen worden, dass RC wieder zu entfernen. Wie dem auch sei. Von dort kommt man nicht mehr weg. ;-)

Nun ja, mit einem Update auf 2.3.5 ist man wieder im Spiel.

Was tatsächlich nicht geprüft wird, ist die Frage, ob die Zielversion durch das Skript abgedeckt ist.


Genau. Ein Nutzer soll die Datei VERSION hochladen, die im config-Verzeichnis zu finden ist. Lädt er nun die aktuelle Version herunter, wird er auch exakt die im Downloadverzeichnis befindliche VERSION nehmen und keine andere/modifizierte. Er wird, wie ich, in dieses Problem laufen. Problematisch ist, dass er das nicht bemerkt. Er hat dann, wie Du schon sagst, 2.4.20 (oder was auch immer) installiert, das Forum gibt sich aber als 2.4.99.1 aus. Noch läuft alles einwandfrei aber ein Update auf 2.4.99.2 wird schief gehen, da die Dateien und die Datenbank nicht auf dem notwendigen Stand (2.4.99.1) sind, die vorausgesetzt werden für das Update. Hier sollten wir in jedem Fall handeln.

Ja. Das bedeutet dann aber auch eine gravierende Umstellung des Updateskripts. Du beschreibst ja eine Lösung, die du für deine Software gefunden hast. Da werde ich mich noch "richtig" einlesen müssen.

Bitte beachte, dass die Änderung auf 128 Zeichen nicht durchgeführt wird, wenn man 2.4.99.1 irgendwie zum Laufen gebracht hat. Das sollte mMn. noch behoben werden.


Sprichst du über die Änderung der Tabelle für Tags?


Was ich meinte ist. Ich habe mein Forum bereits auf Version 2.4.99.1 geupdatet. Ich benötige also nur noch die Änderungen an der Datenbank, die in Version 2.4.99.2 hinzugekommen sind. Die Begrenzung der Felder auf 128 Zeichen würde ich nicht mitbekommen. Ich denke, die CHANGE-Statements müssten in beide if-Bedingungen. Sie werden dann im zweifel doppelt ausgeführt aber besser als gar nicht.

Ah, jetzt verstehe ich. Das werde ich gleich korrigieren.

Ich möchte an dieser Stelle erneut anmerken, dass ich äußerst unzufrieden mit der gegenwärtigen Versionierung bin. Ich sehe nach wie vor keinen Vorteil oder Mehrwert aber durch x Dateien, RC, Sub- und Subsubversionen nur Probleme.

Darüber hatten wir schon einmal geschrieben.

Wir sollten hierüber ab Version 2.5 noch mal sprechen - finde ich.

Grundsätzlich brauchen wir das nicht zu tun. Ich hatte dir irgendwo in den Tiefen dieses Forums schon einmal zugestimmt, finde das Posting allerdings momentan nicht wieder.

Das habe ich noch nicht probiert, ich befürchte aber, dass der ALTER-Query dann abhängig von der SQL-Server-Konfiguration abgebrochen wird.


Das wäre unglücklich und auch eines der Probleme, die ich in unserem Updatescript ausgemacht habe. Wenn das Update schief geht an einer Stelle, dann hat man so eine Zwischenversion, von der man nicht mehr weg kommt. Selbst wenn man das SQL-Statement korrigiert im Script, lässt sich dieses nicht erneut aufrufen, da bereits ein Teil des Updates durchgeführt wurde. Wir benötigen hier ein Rollback oder etwas ähnliches.

Auf Tabellenebene gibt es in MySQL TRANSACTION, wenn die Tabelle vom Typ InnoDB ist. Wie das bei MySQL auf Datenbankebene aussieht, kann ich auf die Schnelle nicht beurteilen. Unsere Tabellen werden ja erst mit 2.4.99.2 alle auf den Typ InnoDB umgestellt. In MS SQL wäre das kein Problem und eins-zwei-fix auf der Datenbankebene eingerichtet.

Ich in meiner Applikation mache es recht simple. Ich erzeuge für jeden SQL eine Subversion z.B. 20180106.0101 (Hauptversion ist das Datum hier 2018-01-06). Beim Update durchlaufe ich die diese Liste und prüfe, welche der Versionen größer ist als die bisherige und führe den SQL aus. Anschließend schreibe ich diese Subversion auch in die Datenbank. Sollte an einer Stelle ein SQL korrupt sein und das Update abbrechen, dann sehe ich, bei welchem SQL dies passiert ist und kann genau dort wieder einsteigen.

Das werde ich mir anschauen müssen. Es liest sich erst einmal schlüssig.

Dadurch, dass ich jedes SQL-Statement mit einer eigenen Version belege, muss ich auch nicht mehr zwischen Installation oder Update unterscheiden. Bei einer Installation durchläuft das Script einfach alle Einträge, beim Update nur die letzten/benötigten.

Sind die Queries bei der Installation nicht gänzlich andere, als bei einem Update?

Bleibt die Frage nach bereits eingetragenen Namen, die länger als 128 Zeichen sind und damit das Update verhindern.


Substr() könnten wir nutzen aber dann erzeugen wir u.U. Kollisionen. Der Name muss in jedem Fall nicht Unique sein, wie es aussieht.

Öhhm, falsche Formulierung gewählt? Der Name, das ist ja die Ursache des diskutierten Problems, muss auf jeden Fall unique sein.

Aber auch hier stellt sich die Frage, wer hat schon einen Namen mit mehr als 50 Zeichen?

Das kann ich für Fremdsprachen nicht beurteilen. Die allermeisten kenne ich nicht. ;-) Ich kann mir aber vorstellen, dass gerade in der deutschen Sprache mit den Möglichkeiten der Zusammensetzung von Worten Witzbolde lange Namen zusammenprökeln.

Mich hat das auch gewundert. Hat Taurec eventuell doch den Upload irgend eines Skripts vergessen? :confused:


Möglich. Er hat aber auch gesagt, dass es mit einer frischen Installation nicht ging. Das würde sich dann (fast) ausschließen, oder?

Stimmt auch wieder.

Tschö, Auge

--
Trenne niemals Müll, denn er hat nur eine Silbe!

Avatar

Update des Forums

by Micha ⌂, Friday, August 16, 2019, 19:17 (1 day, 13 hours, 41 min. ago) @ Auge

Hallo,

Ah, jetzt verstehe ich. Das werde ich gleich korrigieren.

Super!

Sind die Queries bei der Installation nicht gänzlich andere, als bei einem Update?

Nein. Du musst Dir die Installation als ein riesiges Update der Version Null vorstellen. Wenn Du meine SQLs siehst, wirst Du es vermutlich anhand von CREATE, ALTER usw. Statements erkennen. Natürlich muss man Tabellen erzeugen bei der Installation. Beim Update werden diese SQLs aber einfach übersprungen, da jeder einzelne Ausdruck eine Version hat.

Öhhm, falsche Formulierung gewählt? Der Name, das ist ja die Ursache des diskutierten Problems, muss auf jeden Fall unique sein.

[image]

Müsste dann dort nicht Ja stehen? Soweit wie ich das sehe, existiert lediglich ein Index.

--------------

Zum Thema: Ich habe heute versucht, eine Installation der neuen Version vorzunehmen. So konnte ich den neuen Installationsdialog auch mal Kennenlernen. ;-)

Leider bricht die Installation mit Fehlern ab, wobei die letzten beiden sicher Folgefehler sind.

'SQL-Fehler' (MySQL: Index column size too large. The maximum column size is 767 bytes.)
'SQL-Fehler' (MySQL: Index column size too large. The maximum column size is 767 bytes.)
'SQL-Fehler' (MySQL: Table 'mlf2_test_b8_wordlist' doesn't exist)
'SQL-Fehler' (MySQL: Table 'mlf2_test_userdata' doesn't exist)

Leider wird keine Zeilennummer benannt aber da die wordlist und userdata betroffen sind, vermutete ich dort auch das Problem. Eine modifizierte install.sql mit

CREATE TABLE mlf2_userdata (user_id INT(11) NOT NULL AUTO_INCREMENT, user_type tinyint(4) NOT NULL DEFAULT '0', user_name VARCHAR(128) NOT NULL DEFAULT '' COLLATE utf8mb4_bin, user_real_name VARCHAR(255) NOT NULL DEFAULT '', gender tinyint(4) NOT NULL DEFAULT '0', birthday DATE NULL DEFAULT NULL, user_pw VARCHAR(255) NOT NULL DEFAULT '', user_email VARCHAR(255) NOT NULL DEFAULT '', email_contact tinyint(4) DEFAULT '0', user_hp VARCHAR(255) NOT NULL DEFAULT '', user_location VARCHAR(255) NOT NULL DEFAULT '', signature VARCHAR(255) NOT NULL DEFAULT '', profile text NOT NULL, logins INT(11) NOT NULL DEFAULT '0', last_login TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, last_logout TIMESTAMP NULL DEFAULT NULL, user_ip VARCHAR(128) NOT NULL DEFAULT '', registered TIMESTAMP NULL DEFAULT NULL, category_selection VARCHAR(255) DEFAULT NULL, thread_order tinyint(4) NOT NULL DEFAULT '0', user_view tinyint(4) NOT NULL DEFAULT '0', sidebar tinyint(4) NOT NULL DEFAULT '1', fold_threads tinyint(4) NOT NULL DEFAULT '0', thread_display tinyint(4) NOT NULL DEFAULT '0', new_posting_notification tinyint(4) DEFAULT '0', new_user_notification tinyint(4) DEFAULT '0', user_lock tinyint(4) DEFAULT '0', auto_login_code VARCHAR(50) NOT NULL DEFAULT '', pwf_code VARCHAR(50) NOT NULL, activate_code VARCHAR(50) NOT NULL DEFAULT '', LANGUAGE VARCHAR(255) NOT NULL DEFAULT '', time_zone VARCHAR(255) NOT NULL DEFAULT '', time_difference SMALLINT(4) DEFAULT '0', theme VARCHAR(255) NOT NULL DEFAULT '', tou_accepted DATETIME NULL DEFAULT NULL, dps_accepted DATETIME NULL DEFAULT NULL, PRIMARY KEY (user_id), KEY user_type (user_type), KEY user_name (user_name)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

und

CREATE TABLE mlf2_b8_wordlist (`token` VARCHAR(128) NOT NULL, `count_ham` INT UNSIGNED DEFAULT NULL, `count_spam` INT UNSIGNED DEFAULT NULL, PRIMARY KEY (`token`)) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

funktioniert dann ohne Fehlermeldung. Auch hier kann ich nun keine Probleme mit B8 feststellen. Alles läuft soweit.

NACHTRAG: Die so modifizierte Version konnte ich auch bei einem anderen Provider problemlos installieren.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Avatar

Update des Forums und lange Namen

by Micha ⌂, Sunday, August 18, 2019, 07:55 (1 hours, 3 minutes ago) @ Auge

Substr() könnten wir nutzen aber dann erzeugen wir u.U. Kollisionen. Der Name muss in jedem Fall nicht Unique sein, wie es aussieht.


Öhhm, falsche Formulierung gewählt? Der Name, das ist ja die Ursache des diskutierten Problems, muss auf jeden Fall unique sein.

Aber auch hier stellt sich die Frage, wer hat schon einen Namen mit mehr als 50 Zeichen?


Das kann ich für Fremdsprachen nicht beurteilen. Die allermeisten kenne ich nicht. ;-) Ich kann mir aber vorstellen, dass gerade in der deutschen Sprache mit den Möglichkeiten der Zusammensetzung von Worten Witzbolde lange Namen zusammenprökeln.


Ich habe das heute mal in einem Testforum ausprobiert. Hierzu habe ich bemerkt, dass das Forum die Länge bereits (Standardmäßig) begrenzt. Ich musste daher name_maxlength oder name_word_maxlength hochsetzen, damit man überhaupt einen User mit mehr als 70 Zeichen (oder was da stand) anlegen kann. Anschließend habe ich einen 250 langen Zufallsstring erzeugt und einen User angelegt. Wenn ich nun den SQL

ALTER TABLE `mlf2_test_userdata` CHANGE `user_name` `user_name` VARCHAR(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT ''

ausführe, dann erhalte ich eine SQL-Warnung (für jeden zu langen Datensatz):

Warning: #1265 Daten abgeschnitten für Feld 'user_name' in Zeile 139

Ich habe das nun mal mehrfach ausprobiert und am Ende die Länge auf 70 reduziert. Wie man im folgenden Screenshot sehen kann, muss der Name nicht unique sein.

[image]

Oder anders ausgedrückt, das Forumskript prüft bei der Anmeldung, ob es den Namen schon gibt. SQL-seitig wird dies nicht überwacht.

Wenn also das Forum mit den Standardeinstellungen läuft, dann sollte es kein Problem geben, da hier per default nur 70? Zeichen vorgesehen sind. Ich denke, das wird auf 99,99 % aller Installationen zutreffen.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

RSS Feed of thread
powered by my little forum