Upgrade von Modulen

[Katerchen]

Hallo!

Derzeit wage ich mich an meine erste Erweiterung eines Moduls. Konkret geht es um die "Image Gallery 1.9e", der ich die Möglichkeit verpassen möchte, Bilder in selbst zu wählenden Verzeichnissen zu speichern, und bei mehrfacher Nutzung des Moduls für die Bilder jeder Seite ein eigenes Verzeichnis auszuwählen. Der erste Prototyp funktioniert schon ganz gut, allerdings möchte ich noch ein wenig testen.

Bei der Gelegenheit will ich mich auch ein wenig in die "saubere" Erstellung von Modulen einarbeiten, und dazu gehört ja auch eine passende Datei upgrade.php, da ein Feld in eine Datenbanktabelle hinzufügt werden soll. PHP- und MySQL-mäßig kriege ich das hin, doch was wird hier vorausgesetzt? Stets die letzte Version? Oder soll das Update-Script auch Aktionen früherer Upgrades "mitnehmen", damit das Upgrade eben auch von früheren Versionen funktioniert?

Im Image Gallery-Modul finde ich z.B. überhaupt keine upgrade.php, dafür eine update_gallery_to17 .php und eine update_gallery_from 17_to18.php, die ja nicht automatisch ausgeführt werden, in der jedoch auch jede Menge Tabellenerweiterung en gemacht werden und vermutlich zur manuellen Ausführung gedacht sind. (Ein update_gallery_from 18_to19.php o.ä. gibt es nicht.)

Wenn Interesse besteht, stelle ich dieses erweiterte Modul natürlich der Allgemeinheit zur Verfügung.

[thorn]

Hallo,

man sollte updates auch von älteren Versionen unterstützen.

Ein guter Aufbau der upgrade.php ist meiner Meinung nach so:

Code:

// #######################################################
// VERSION < 2.5
if($module_version<'2.5') {
  // tue was getan werden muss
}

// #######################################################
// VERSION < 2.5.1
if($module_version<'2.5.1') {
  // tue was getan werden muss
}

// #######################################################
// VERSION < 2.6.2
if($module_version<'2.6.2') {
  // tue was getan werden muss
}

Die Benutzung von version_compare() wäre zwar viel sinnvoller, aber leider benutzt WB schon immer einen einfachen Stringvergleich, also muß das hier auch so sein.

Zu den Versionsnummern:
Diese ganzen Buchstaben, Bindestrich-Nummern und ähnliches sollten wir langsam mal auf eine vernünftige Form bringen.
Siehe als Empfehlung http://de.wikipedia.org/wiki/Versionsnummer
Gute Nummern sind also
0.1
1.0
1.1
1.1.1
1.1.9
1.1.10
1.1.11
1.2
1.2.1
1.54.500
1.54.501
und so weiter

Schlecht ist
1.9e
1.2.02
1.3-beta_433
oder ähnliches Zeug

EDIT: Oh, s***! Erst denken, dann posten wäre manchmal sinnvoll...
Natürlich können Versionen wie 1.2.12 bei websitebaker nicht funktionieren, wenn es vorher schon eine 1.2.2 gab, da (als Stringvergleich) "1.2.2" > "1.2.12"  (während version_compare() das natürlich richtig machen würde: version_compare('1.2.2', '1.2.12', '<') == TRUE)

thorn.

[Katerchen]

Ok, ich versuche, die beiden Scripts in mein Upgrade-Script zu integrieren.

Ein ähnliches Versionsnummernsche ma wie das von Dir genannte verwende ich auch gerne. Die derzeitige Version heißt leider 1.9e, ich hätte meine gerne 1.9.1 genannt, aber dann funktioniert das Upgrade nicht, da "1.9.1"<"1.9e". Also nenne ich sie vorläufig 1.9f.0 oder so ähnlich (für eine 2.0 sind die Änderungen m.E. doch zu wenig). Wie sollten Betaversionen am besten gekennzeichnet werden? Irgendwas hinter die endgültige Versionsnummer zu hängen, funktioniert ja wegen des Stringvergleichs nicht.

"1.1.9" hat jedoch auch Nachteile, da "1.1.10" nicht mehr geht...

[thorn]

"1.1.9" hat jedoch auch Nachteile, da "1.1.10" nicht mehr geht...

Solange man von einem Stringvergleich ausgeht hilft hier nur "1.1.09" zu schreiben, oder besser noch "1.01.09", dann hat man "1.01.09" < "1.01.10". (Sieht zwar scheiße aus - funktioniert dann aber auch noch mit string_compare()).

Wie sollten Betaversionen am besten gekennzeichnet werden? Irgendwas hinter die endgültige Versionsnummer zu hängen, funktioniert ja wegen des Stringvergleichs nicht.

Stimmt, da bleibt nur mit einer "tieferen" Versionsnummer zu arbeiten:
1.09.04 - letzte Version
1.09.04.01 -erste Beta
1.09.04.02 -zweite Beta
1.09.05 - neue Version
Äh, ne, auch irgendwie Mist.

thorn.

[Ruud]

Excuse me for doing this in English..

I am now using a nice piece of code I found in the WB2.7 upgrade script.
I modified it a little bit so it would not display unneeded messages.

There is a function db_add_field:

Code:

<?php //used for colorcoding this code block

function db_add_field($field, $table, $desc) {
    global $database;
    $table = TABLE_PREFIX.$table;
    $query = $database->query("DESCRIBE $table '$field'");
    if(!$query || $query->numRows() == 0) { // add field
        $query = $database->query("ALTER TABLE $table ADD $field $desc");
        echo (mysql_error()?mysql_error().'<br />':'');
        $query = $database->query("DESCRIBE $table '$field'");
        echo (mysql_error()?mysql_error().'<br />':'');
    }
}

When this is called it checks if the field exists, if not it is added.

Call it with a oneliner for each added field:

Code:

<?php //used for colorcoding this code block

// Safely add field that was added in v0.14    
db_add_field("extrafield", "mod_my_module", "INTEGER UNSIGNED NOT NULL DEFAULT '0'");

// Safely add field that was added in v0.15    
db_add_field("morefields", "mod_my_module", "VARCHAR(45)  NOT NULL DEFAULT 'default value'");

For every update you can just add the lines for that update, but without the need of removing previous updates.

Ruud

[Katerchen]

I am now using a nice piece of code I found in the WB2.7 upgrade script.
I modified it a little bit so it would not display unneeded messages.

Brilliant idea! I have just implemented it in the file upgrade.php for the new version of the image gallery!