Vorteil von der configdb

[Frank_Huber]

weitere kleine Hürde:

gplot Dateien müssen importiert werden. sonst funktionieren sie nicht.

beim Importieren mit voller Pfadangebe funktionierren die gplot auch nicht. (/opt/fhem/www/gplot/...)
Es muss mit Pfad ./www/gplot/... importiert werden.

sehr schön:
Importierte Dateien sind auch unter "Edit files" verfügbar und Änderungen werden wieder in die DB gespeichert!

[betateilchen]

Hallo Frank,

Einiges von dem, was Du hier so zusammenschreibst, sind schlichtweg falsche Behauptungen.

gplot Dateien müssen importiert werden. sonst funktionieren sie nicht.

Um genau zu sein:

gplot Dateien, die zum Zeitpunkt der Migration in irgendeinem existierenden SVG device verwendet werden, werden sehr wohl automatisch importiert.
Vom Benutzer neu erstellte gplot Dateien werden automatisch in die configDB abgelegt.

Die Einschränkung "zum Zeitpunkt ... verwendet" gilt auch für die anderen Module, deren spezifische Dateien migriert werden.

beim Importieren mit voller Pfadangebe funktionierren die gplot auch nicht. (/opt/fhem/www/gplot/...)
Es muss mit Pfad ./www/gplot/... importiert werden.

Das ist ein völlig logisches Verhalten, das von SVG vorgegeben ist und der größtmöglichen Transparenz geschuldet ist. Schließlich gibst Du bei der Definition eines SVG devices auch keinen vollständigen Pfad zur gplot Datei an.

Ich sehe da nur eine Schwierigkeit, wenn ich z.B. zwei/drei gplot importiere sehe ich nicht wirklich welche in der DB und welche auf file sind.

Doch, man kann das erkennen. Zum Beispiel, wenn man den Mauszeiger auf den Link zur Datei bei "Edit files" stellt und sich den Link anschaut.

Code Auswählen Erweitern

https://.../fhem?cmd=style%20edit%20SVG_dbLog_1.gplot%20configDB&fwcsrf=...

wenn - wie im Beispiel - die Kennzeichnung "configDB" im Link steckt, kommt die Datei aus der Datenbank und wird auch wieder dorthin zurückgeschrieben.

Wenn die Testphase rum ist und ich wirklich umsteige werde ich "deleteimported" setzen.

Davon rate ich regelmäßig ab und ich überlege sogar, dieses Attribut wieder zu entfernen.
Du solltest lieber "filemove" anstatt "fileimport" verwenden, dann brauchst Du das Attribut nicht.

Aber dazu muss ich dann auch erst noch rauskriegen wie man mehrer Instanzen in die DB bekommt.

Das wirst Du nicht rauskriegen und ich werde das nie zu einem offiziellen Feature machen.
Die damit verbundenen Risiken sind mir einfach zu groß, das ist nicht supportbar.

Im Wiki habe ich gleich ein paar Kleinigkeiten dazu ergänzt,
...
(@betateilchen: Deine Meinung zum Thema Wiki ist bekannt, ich werde es knapp halten und habe nicht die Absicht, das wesentlich auszuweiten).

Der Blitz soll Dich beim Kacken treffen ...

---

[Frank_Huber]

Und damit ist mein configdb Test beendet, da bleibe ich dann lieber bei der cfg.

Gründe:
1. kein wirklicher Vorteil zu sehen. Es wird eher unübersichtlicher.
2. keine wirkliche Transparenz was in der DB ist und was nicht. (ich schaue nicht den Link jedes Elements an um zu sehen wo es liegt)
3. gpolt Dateien müssen in der DB sein. Eine Datei wird schlicht ohne Fehlermeldung ignoriert.
    (ich könnte erklären wie es bei meinen Tests dazu kam, aber das interessiert ja eh nicht, is ja ne falsche Behauptung)
4. Doku. Ist für ein Modul das so zentral eingreift schlicht zu knapp gehalten und wichtige Themen fehlen gänzlich.
5. Mir persönlich fehlt ein Device in FHEM über das die Befehle abgesetzt werden, die Attribute zu sehen sind und evtl andere Status Readings.
6. Ich lege sicher nicht für jede Instanz eine eigene Datenbank an.

[Beta-User]

Danke auf alle Fälle für's testen!

Kurz meine Gedanken dazu:

Dass es insbesondere für erfahrenere User keine massiven Verbesserungen bringt, hatte ich hoffentlich hinreichend deutlich gemacht. Was Übersichtlichkeit angeht, hat das eine subjektive Komponente, das war mir bisher nicht in der Deutichkeit klar. Mir genügen z.B. die Ergebnisse aus "configdb filelist", aber ich mache eben auch vieles über die Kommandozeile und hatte bisher auch nicht den Wunsch, ein "Objekt" (ähnlich "global"?) zu haben, um irgendwelche Statusinfos zu dem zu haben, was in der DB ist. Aber andere Gewohnheiten, andere Erwartungen; das ist m.E. grundsätzlich ok.

Nutzt man configdb von Anfang an, sind in der Regel alle "externen" Konfigurationsfiles in der DB, und zwar automatisch. Von daher bin ich (als User) eher negativ überrascht, wenn ein Modul hier abweichendes Verhalten zeigt (und hatte in betateilchens Antwort das erste mal bewußt wahrgenommen, dass genutzte .plot importiert werden; das "was wird importiert" war (und ist in Teilen) auch eine der für mich offenen Fragen). "Direkteinsteigern" dürften sich daher Umstellungsfragen nicht in derselben Weise stellen und der Hinweis, dass man besser gleich "filemove" machen sollte, ist auch sehr wertvoll.

M.E. ist die ziemlich knappe Doku auch völlig ok, überbordende Detailinfos helfen in der Regel nicht weiter, aber grade die sehr spärlichen Infos, die man zu manchen Detailfragen finden kann (wenn man weiß, wonach man sucht?), empfinde ich auch als nicht unbedingt förderlich für den Gedanken, configDB auch Einsteigern zu empfehlen.

Wie dem auch sei, bin mal gespannt, ob es noch Rückmeldungen von weiteren Testern gibt...?

[DJAlex]

Ich hab heute ein neues frisches System aufgesetzt und wollte zum testen mal gleich mit configdb anfangen. Klappt soweit auch bis jetzt gut.
Eine Frage hätte ich vorab aber schon mal.
Das ist meine config:

Code Auswählen Erweitern

%dbconfig= (
connection => "mysql:database=HausautomationConf;host=xx.xx.xx.xxx;port=3307",
user => "xxx",
password => "xxx"
);



dafür hatte ich statt database dbname drinstehen. Funktioniert wohl beide. Gibt es da einen unterschied was ist das richtige?
Eine Kleinigkeit noch. Ich hab den dump Befehl testen wollen. Leider wird da bei mir nichts gespeichert. Die aus gäbe ist 0byte. In der db ist aber was drin.
Im Logfile zeigt er nur folgendes an.

Code Auswählen Erweitern

sh: 1: Syntax error: "&" unexpected
Ich hab den Dump Befehl jetzt nochmal mit einem anderen Datenbank Benutzer getestet. Wenn ich einen nehme der keine Sonderzeichen im Passwort hat funktioniert es wohl...

[betateilchen]

dafür hatte ich statt database dbname drinstehen. Funktioniert wohl beide. Gibt es da einen unterschied was ist das richtige?

In der Dokumentation zum perl Datenbankmodul DBD::mysql ist nur "database" beschrieben.

Ich hab den Dump Befehl jetzt nochmal mit einem anderen Datenbank Benutzer getestet. Wenn ich einen nehme der keine Sonderzeichen im Passwort hat funktioniert es wohl...

Dann hast Du die Lösung ja schon selbst gefunden

Ich hab heute ein neues frisches System aufgesetzt und wollte zum testen mal gleich mit configdb anfangen. Klappt soweit auch bis jetzt gut.

Guter Plan!

[DJAlex]

Dann hast Du die Lösung ja schon selbst gefunden

Das war eigentlich mehr ein Hinweis darauf das ich das nicht ganz konsistent finde, dass ich die Konfiguration zwar mit Sonderzeichen erstellen kann und alles normal funktioniert aber der "dump" Befehl damit nicht geht. Die Sonderzeichen sind bei mir mit \ maskiert. Ansonsten Scheint bis jetzt alles gut zu funktionieren

[betateilchen]

Hast Du mal probiert, ob mysqldump auf der Betriebssystemebene mit Deinen Sonderzeichen klarkommt?