Datenbankversionierung

[following]

Als Übegangsschritt bis zur geplanten Datenbankversionierung gibt es ab sofort ein Datenbank-Changelog:

https://github.com/OpencachingDeutschla ... hanges.txt

Wenn dort geänderte Trigger aufgeführt sind muss stored-proc/maintain.php ausgeführt werden; sonstige Änderungen sind von Hand per phpMyAdmin einzupflegen.

@Micha
Letzteres hatte ich vergessen, bei unserer Entwicklersystem-Session zu erwähnen. Kannst gleich mal üben und das neue Feld "is_publishdate" in der Tabelle "caches" eintragen   (vgl. caches.sql):

1. http://oc-devel/pma/
2. Login als root mit Passwort "developer"
3. links die Datenbank "opencaching" wählen
4. links die Tabelle "caches" wählen
5. oben "Struktur" wählen
6. 1 Feld(er) hinzufügen nach date_created
7. Feld: "is_publishdate", Typ: TINYINT, Standard: Benutzerdefiniert: 0
8. Speichern

[4_Vs]

Hi Peter,

ich war heute in pma und wollte das neue Feld anlegen, allerdings existierte das schon:

Code: Alles auswählen

Fehler
SQL-Befehl:

ALTER TABLE  `caches` ADD  `is_publishdate` TINYINT NOT NULL DEFAULT  '0' AFTER  `date_created`

MySQL meldet: 

#1060 - Duplicate column name 'is_publishdate'

[following]

[quote="4_Vs"]
ich war heute in pma und wollte das neue Feld anlegen, allerdings existierte das schon:
[/quote]

ah, ok, dann war das schon in dem Datenbankupdate drin das ich dir eingespielt hatte

[following]

Inzwischen gibt es ein Script, das das komplette Datenbankupdate mit Ausnahme der Tabellenänderungen übernimmt. Damit ist der Gesamtablauf wie folgt:

1. htdocs/doc/sql/db-changes.txt prüfen
2. Änderungen von Hand per phpMyAdmin einpflegen (Trigger ausgenommen)
3. php bin/dbupdate.php


Der letzte Schritt ist dann, den Rest auch noch zu automatisieren, so wie von Robert angedacht. Damit das mit dem Git-Workflow harmoniert wird es neben den .sql-Patches für neue Änderungen bei Bedarf auf welche geben, die nach dem Ausbau eines instabilen Code-Patches die Datenbankänderung wieder rückgängig machen.

Ich denke dass die .sql-Patchdateien halbautomatisch erzeugbar sind: problematisch sind der äußerst seltene Fall einer Feld-Umbenennung, und Änderungen an Feldern, bei denen zusätzlich Daten zu verarbeiten sind, die sich nicht in data.sql befinden - z.B. ein neues Feld mit bestimmten Werten aus anderen Feldern initialisieren. D.h. der Ablauf könnte sein:

1. Die Entwickler checken Änderungen der Datenbankstrukturen per doc/sql/tables ein.
2. Zusätzliche SQL-Kommandos, um Daten weiter zu verarbeiten, sind im Commit-Kommentar zu dokumentieren.
3. Der Entwicklungsleiter merged (in seinem lokalen Klon) den Commit in den master und lässt anschließend ein Script laufen, das eine .sql-Datei mit dem Datenbankpatch erzeugt.
4. Wenn spezielle Kommandos nötig sind, arbeitet er sie von Hand in die .sql-Datei ein.
5. Test
6. Die .sql-Datei wird zusammen mit der Änderung am master hochgeladen.
7. Das bin/dbupdate-Script erkennt, wenn es neue .sql-Dateien gibt, und spielt sie vor dem übrigen Datenbankupdate ein.

Wer mag diese Aufgabe übernehmen und das Script für Punkt 3 schreiben? Es muss ein "git diff htdocs/sql/tables/*" in Bezug auf den Commit-Stand der letzten .sql-Datei machen (die Commit-ID kann z.B. in einem Kommentar in der .sql-Datei hinterlegt sein), daraus entsprechende CREATE/ALTER/DROP-TABLE/INDEX-Statements erzeugen und das Ganze zusammen mit der aktuellen commit-ID in eine neue .sql-Datei schreiben.

[oliver]

[quote="following"]Wer mag diese Aufgabe übernehmen und das Script für Punkt 3 schreiben?[/quote]

Ich hatte mal damit experimentiert und kann gerne diesen Prototyp beisteuern. Der muss zwar wohl nochmals neu geschrieben werden, aber vielleicht sind ja ein paar Sachen als Anregung für das neue Skript dabei. Die andere Frage ist, ob es da nicht schon fertige Lösungen dafür gibt. Vor 5 etwa Jahren hab ich mal gesucht und nix gefunden, aber vielleicht gibt es ja mittlerweile Projekte die sich damit beschäftigen. Ist ja ein Standard-Problem in der Informatik ...

[following]

Ich hatte vor ein paar Wochen auch danach gesucht und nichts für unsere Zwecke brauchbares gefunden.

Kannst du dein Script einfach mal als

Code: Alles auswählen

 hier reinstellen? Vielleicht mag es ja jemand als Vorlage nehmen und es zuende führen.

[oliver]

Hat mehr als 20kB ... deshalb als Anhang ....


Edit: Die Funktion PMA_splitSqlFile() hatte ich damals von phpBB geklaut ... die extrahiert die einzelnen SQL-Statements in einer SQL-Datei ...

[following]

Die OKAPI hat eine Datenbankversionierung.

https://github.com/OpencachingDeutschla ... or.inc.php
https://github.com/OpencachingDeutschla ... update.php

[following]

Es ist nun eine einfache Datenbankversionierung vorhanden. Wenn eine OC-Installation mindestens auf diesem Stand ist, werden alle weiteren Änderungen per

Code: Alles auswählen

php bin/dbupdate.php

automatisch eingespielt. Es braucht also nur noch ein 'git pull' und ein 'dbupate', um ein Entwicklersystem zu aktualisieren. (+ 'wget localhost/okapi/update', wenn man die OKAPI verwendet).

[Schrottie]

Super!
Und ich sehe schon, ich muss mir ganz dringend mal die Zeit nehmen um mein Develsystem auf aktuellen Stand zu bringen.