plugin database - Wechsel von sqlite3 zu mysql?

[Morg]

Moin,

ich nutze seit einer ganzen Weile das database-Plugin aus master-1.7.1 mit sqlite3.

Im Rahmen von einigen Umstellungen (u.a. Umstellung der RasPis von SD-Karte auf NFS) überlege ich, das database-Plugin auf MySQL umzustellen, da ich sowieso den MySQL-Server laufen habe.

Die grundsätzliche Umstellung ist ja kein Problem - aber gibt einen praktikablen Weg, die Daten zu übernehmen?

Gruß
Sebastian

[Msinn]

Bisher hat sich niemand gefunden, der eine Datenüberame beschrieben oder automatisiert hat.

Zumal es auch noch einen Unterschied macht von welcher SQLite Datenbank zu kommst. Die SQLite Datenbank der sqlite Plugins haben eine andere Struktur als die Datenbank des database Plugins.

[Morg]

Naja, ich wollte schon "innerhalb" des database-Plugins bleiben.

Aber ich habe verstanden, was du sagen wolltest Muss ich doch noch lernen, wie sqlite3 funktioniert...

[Msinn]

SQLite ist dabei der einfache Teil da gibt es graphische Tools, (wie für MySQL auch) mit denen Du die Daten exportieren/dumpen kannst. Interessant wird es bei der Anpassung der Daten an die neue Struktur. Das sollte bei SQLite(database plugin) zu mysql(database plugin) nicht zu kompliziert sein, aber ein einfacher Import der Daten ist es halt auch nicht.

[Morg]

Manuell war es jetzt relativ einfach - mit sqlite3 smarthome.db .dump exportieren, von einem Skript die Syntax auf MySQL umschreiben lassen (nicht erfolgreich, da war noch einiges an Handarbeit notwendig) undin MySQL importieren.

Es gab ein paar Probleme, shng mit den neuen Daten zu starten. Die Einträge in den Systemtabellen schienen inkonsistent zu sein.

Ich habe die Datenbank geleert und shng gestartet, so dass die gesamte Struktur neu und korrekt angelegt wurde. Nachdem die ersten neuen Daten geschrieben waren, habe ich dann die alten Daten importiert.

Vor dem Import sollte man die Daten im SQL-Dump noch optimieren - der Import von einem Datensatz pro Zeile (jeweils eigenes INSERT-Statement) ist bei vielen Zeilen doch eher.. langsam (ich wusste gar nicht, dass da schon 2.4 Mio Zeilen drin waren - das dauert auch nur knapp 20 Stunden - und das nicht auf einem Raspi, sondern auf einem Xeon E3-1200... )

Einen automatischen Konverter könnte man wahrscheinlich am besten im Database-Plugin als "externe" Funktion implementieren, weil der gesamte Datensatz direkt gelesen und in der neuen DB neu erzeugt werden könnte, ohne über langwierige Textex- und -importe und Formatumschreibungen gehen zu müssen...

[bmx]

Ich hätte das vermutlich versucht anders aufzuziehen:

Das Database Plugin soll angeblich Multiinstanzfähig sein. Also könnte man theoretisch eine zweite Instanz mit mysql machen und dann über die Lesen und wieder Schreiben Funktion in die zweite Instanz die Daten übertragen. Das dauert eventuell noch länger als die 20 Stunden aber hat den Vorteil, das es auch nebenher passieren könnte.
Aber da ich nicht konvertieren will, ist das ohnehin eher rein akademisch :-)

[Morg]

Das stimmt schon

Ich bin aber nicht sicher, ob das database-Plugin darauf vorbereitet ist, die Gesamtdaten zu lesen. Vielleicht geht das über die API, da habe ich jetzt aber nicht im Detail reingeschaut.

Ich bezweifle auch, dass das eine Massenanwendung wird

[Msinn]

Ja, bmxp meinte sicherlich über das API. Dazu eine Logik schreiben, die das API anspricht. Damit geht man den Problemen aus dem Weg, die durch die unterschiedlichen Datenbank Systemen entstehen.

Den Ansatz finde ich eigentlich recht sympathisch. Probiert habe ich es allerdings nicht.

Die Einträge in den Systemtabellen schienen inkonsistent zu sein

Davon würde ich ausgehen. Jedes Datenbank System hat eigene Vorstellungen wie es die Nutzertabellen, etc. verwaltet.

[Morg]

Damit meinte ich die Einträge in der database_version-Tabelle (also der "Systemtabelle" des Plugins). Beim ersten Start hat das Plugin abgebrochen, weil es eine Tabelle (log) nicht anlegen konnte; beim zweiten Mal Fehler in database_version gefunden.

Die Nutzertabellen usw. werden ja von shng nicht angefasst... (hoffe ich )