configDB - suche Tipp Datenbankumstellung

[SusisStrolch]

Momentan läuft meine configDB gegen MySQL auf meiner Synology.
Da ich die Abhängigkeiten von Software-Updates ausklammern möchte, suche ich nun eine Vorgehensweise
um auf SQLite umzustellen.

Wie ist in diesem Falle die "Best Practice"?

[betateilchen]

Best practice: tu es nicht.

[SusisStrolch]

Was sind die Beweggründe?

Meine sind relativ einfach... Beim Update des letzten SQL-Packages war das System 5Std. damit beschäftigt, Kopien meiner diversen Datenbanken anzulegen.
DbLog sollte diese Auszeit mit seinem Caching-Mechanismus schaffen.
Für configDB gibt es keinen Cache, daher die Idee das ganze in eine SQLite zu legen, so dass zumindest die Basisfunktionen von FHEM weiterhin gegeben sind.

[dev0]

@SusisStrolch: Benutze die fhem.cfg statt configdb, dann hast Du diese selbstgemachten Probleme nicht. Es gibt mMn wenig Szenarien, in denen configdb Sinn macht.

[betateilchen]

Sowas kann nur jemand schreiben, der sich noch nie mit den Möglichkeiten, die configDB inzwischen bietet, auseinandergesetzt hat.

[betateilchen]

Was sind die Beweggründe?

Eigentlich egal. Wenn du es unbedingt tun willst...

- erstelle dir mit "configdb filelist" eine Liste aller Dateien, die in der configDB gespeichert sind.
- exportiere alle Dateien mit "configdb fileexport all" ins Dateisystem
- "attr global configfile fhem.cfg" anschliessend ein "save" und ein shutdown.

Nun kannst Du die Datenbank umstellen, danach startest Du FHEM einmal mit "fhem.cfg" und startest die Migration mit "configdb migrate". Danach FHEM wieder mit configDB starten und die evtl. fehlenden Dateien noch importieren.

Fertig.

[SusisStrolch]

@SusisStrolch: Benutze die fhem.cfg statt configdb, dann hast Du diese selbstgemachten Probleme nicht. Es gibt mMn wenig Szenarien, in denen configdb Sinn macht.

Ich muss ganz ehrlich sagen, dass ich bei configdb mehr Vorteile als bei fhem.cfg sehe - alleine die Versionierung finde ich einfach genial.

- erstelle dir mit "configdb filelist" eine Liste aller Dateien, die in der configDB gespeichert sind.
...

Ok - d.h. das ist der Aufwand wenn ich von MariaDB auf SQLite gehen würde.

Ich nehme an, dass es bei MariaDB -> MariaDB ausreicht, einen mysqldump | mysql Import zu fahren?

[betateilchen]

Ich nehme an, dass es bei MariaDB -> MariaDB ausreicht, einen mysqldump | mysql Import zu fahren?

Kommt drauf an, wie das mit den Binärdateien bei Deinem Dump funktioniert.

[dev0]

Ich muss ganz ehrlich sagen, dass ich bei configdb mehr Vorteile als bei fhem.cfg sehe - alleine die Versionierung finde ich einfach genial.

Versionierung kann man auch anders bewerkstelligen. Einen weiteren Nachteil sehe ich allerdings in der Unberechenbarkeit des Entwicklers, Module nach ./contrib zu verschieben, wenn Kritik mit Bashing verwechselt wird. Wenn man auf Dauer keinen Support benötigt, dann spielt das allerdings keine Rolle.

[betateilchen]

Nur mal so am Rande (fällt Dir eigentlich auf, wie weit Du schon wieder im offtopic bist?)

• soviel bashing, dass ich configDB nach ./contrib verschieben würde, schaffst selbst Du nicht
• die Möglichkeit der Versionierung ist nicht der einzige (und auch für viele Anwender nicht der wichtigste) Grund für den Einsatz von configDB
• wenn Du am Support für configDB etwas auszusetzen hast, dann bitte sachlich und nicht mit solchen leeren Worthülsen wie hier im Thread
• von mir wurde noch kein Modul tatsächlich wegen bashing nach ./contrib verschoben
• auch für Module, die ich nach ./contrib verschoben habe, leiste ich in aller Regel noch Support ^*

^* die vom DWD in den vergangenen Tagen angekündigte nächste große Umstellung in der Grundversorgung von Wetterdaten werde ich in 55_GDS.pm tatsächlich nicht mehr umsetzen.

[Burny4600]

Was ist eigentlich der Vorteil von configDB gegenüber der fhem.cfg.

[betateilchen]

Diese Frage ist bereits ca. 728 Mal hier im Forum beantwortet. Einfach mal ein bisschen lesen 😀

Es gibt nicht "den" (im Sinne von: nur einen) Vorteil, man muss das Gesamtkonzept betrachten.

[Burny4600]

Sorry das ich fragte, aber ich war nicht auf einen Rätseltripp.
Dann lasse ich es leiber wie es ist.

[betateilchen]

Das hat überhaupt nichts mit Ratespiel zu tun.

Sorry, aber das Thema ist wirklich bis zum Exzess durchdiskutiert und ich habe keine Lust, das für jeden Fragesteller wieder von vorne zu beginnen, nur weil er zu bequem ist, die vorhandene Dokumentation zu lesen.

Eine grobe Orientierung gibt alleine schon die commandref ("help configdb" im Frintend einegeben)

[Beta-User]

Kleiner Erfahrungsbericht in dieser off-Topic-Sache, da ich die Frage nach den Vorteilen irgendwann in der Vergangenheit auch mal gestellt hatte.

Inwieweit man als reiner Anwender die commandref - abgesehen von der Versionierung, die dort gut beschrieben ist - für aufschlußreich halten kann, was die Vorteile angeht, mag jeder für sich selbst beurteilen und welche Stichworte man braucht, um die richtigen Threads zu finden, hat mich irgendwann auch nicht mehr interessiert .

Was mir zu fhem.cfg-Zeiten hin und wieder passiert ist: Meine 1-Wire-DS18B20 waren verschwunden... Ich habe dann regelmäßig das entsprechende include wieder aus dem Backup herstellen dürfen, wenn ich beim Speichern übersehen hatte, dass der Bus ein Problem hat. Ob das mit dem Umstieg auf configDB wirklich technisch zusammenhängt, kann ich als Laie nicht beurteilen, aber jedenfalls ist mir das - oder etwas ähnliches -  nach dem Umstieg nicht mehr passiert.

Echte Nachteile konnte ich bisher nicht feststellen, für Notfälle speichere ich über den attr global-Weg immer mal wieder eine aktuelle fhem.cfg raus und habe so auch den Umzug vom PI auf die Amlogic-Box gemacht. Die DB liegt bei mir nicht auf einem Netzwerkserver, sondern lokal.

Das einzige Mal, bei dem ich den Eindruck hatte, dass ein Modul nicht korrekt mit configDB zusammenarbeitet, war mit hminfo (Abgleich der templisten); näher untersucht habe ich das allerdings bislang nicht, ist allenfalls ein Schönheitsfehlerchen (wenn, dann von hminfo ).

Gruß, Beta-User

[dev0]

soviel bashing, dass ich configDB nach ./contrib verschieben würde, schaffst selbst Du nicht

Wenn DU meine Meinung/Einschätzung über des configdb Modul als Bashing ansiehst, dann ist das so, aber es ist in keinster Weise so gemeint.

von mir wurde noch kein Modul tatsächlich wegen bashing nach ./contrib verschoben

Im nächsten offiziellen Release von fhem wird GDS nicht mehr in der Standardauslieferung enthalten sein, sondern nur noch in ./contrib. Ich habe das permanente bashing gegen das Modul hier im Forum einfach satt. Das muss ich mich mir einfach nicht mehr antun.

[betateilchen]

GDS war im Mai 2016 aufgrund der immer wieder auftretenden Änderungen seitens DWD schon ein ziemlich "totes" Modul, was aber viele Leute schon damals nicht verstanden hatten. Was hier im Forum dazu kam, war nur die Spitze des Eisbergs. Der ausschlaggebende Punkt für das Verschieben waren die emails, die seinerzeit bei mir ankamen. Darin ging es meistens nicht mehr um das Modul, sondern gegen meine Person.

Trotzdem ist das Modul - auch in ./contrib - bis heute bei mir "in der Wartung".

Aus der Verlegung eines einzigen Moduls nach contrib gleich eine "Unberechenbarkeit des Entwicklers" herzuleiten und zu unterstellen, finde ich eine ziemliche Unverschämtheit. Noch dazu, wo die Verschiebung des Moduls bis heute keinerlei negative Auswirkungen auf die Anwender hat.

in der Unberechenbarkeit des Entwicklers, Module nach ./contrib zu verschieben,

Aber nun sind wir tatsächlich völlig im offtopic.

[betateilchen]

Ok - d.h. das ist der Aufwand wenn ich von MariaDB auf SQLite gehen würde.

Ich nehme an, dass es bei MariaDB -> MariaDB ausreicht, einen mysqldump | mysql Import zu fahren?

Für das "Problem" mit den abgelegten Binärdateien in configDB wird es in den nächsten Wochen eine Neuerung geben, dann können auch diese Dateien einfach per sql-dump exportiert und importiert werden. Dazu wird das Schreiben und Lesen solcher Dateien in der Datenbank künftig base64-codiert erfolgen.

[CoolTux]

Hallo Udo,

Das erwähnte Packet libmime-base64-perl ist ein virtuelles Packet was eigentlich nur perl bereit stellt. Gibt es diesbezüglich noch etwas zu beachten oder ist alles ok wenn mein System meldet perl ist bereits die neuste Version?


Grüße

[betateilchen]

Ich gehe davon aus, dass in 99,99% aller Fälle kein Handlungsbedarf besteht.
Wenn Du morgen keine Meldung im Logfile findest, ist alles ok.

Aber für die 0,01% der Fälle, die man nicht vorhersehen kann, wollte ich mit dem Ankündigungs-Thread zumindest rechtzeitig informiert haben, ausserdem dient der Thread als "Antworthilfe" zum Verlinken, falls doch irgendjemand im Forum fragt, was "die Fehlermeldung im Log" bedeutet. Man kennt ja inzwischen seine Pappenheimer

[SusisStrolch]

Für das "Problem" mit den abgelegten Binärdateien in configDB wird es in den nächsten Wochen eine Neuerung geben, dann können auch diese Dateien einfach per sql-dump exportiert und importiert werden.

Super!