Avatar

Update des Forums (German / Deutsch)

by Auge ⌂ @, Friday, August 16, 2019, 10:27 (94 days 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!


Complete thread:

 RSS Feed of thread

powered by my little forum