fhem configuration in sql-DB ablegen - besteht Interesse?

[betateilchen]

aber contrib wird nicht per update ausgeliefert, und das bleibt so.

ok, das war mir nicht bewusst.

Zweitens bitte beachten bei edits: diese werden per email nicht ausgeliefert,

Das weiss ich sehr wohl. Wer sich auf die email-Benachrichtigung einer Forumsoftware (egal welcher) verlässt, darf nie davon ausgehen, alles mitzukriegen. Dafür kann aber die Software nix, und daraus kann man auch einem User keinen Vorwurf machen. Das ist ein typisches Problem von Anwendern, die irgendwann von Newsgroup zu Forumsoftware umsteigen mussten und gedanklich an ihren alten Zöpfen festhalten. Aber irgendwann lernt das erfahrungsgemäß auch der letzte Umsteiger. Die email-Benachrichtigung ist für mich wie ein goldenes Fußkettchen: hübsch, aber nutzlos. Deshalb nutze ich die seit Ewigkeiten in keinem Forum mehr.

da ich auf die schnelle kein generisches Datenbank-Backup programmieren wollte,

Niemand hat von Dir verlangt, dass Du ein Datenbank-Backup programmieren sollst.

Ich habe update modifiziert, so dass ohne gesetztes backup_before_update und configDB kein backup gemacht wird.
...
backup liefert ab sofort bei configDB eine Fehlermeldung zurueck,  und ohne die FHEM Konfiguration ein Backup mAn sinnlos ist.

Dass nun aber gar kein Backup mehr gemacht wird, halte ich aber auch nicht für die richtige Lösung.
Hätten wir nicht besser erstmal über eine sinnvolle Lösung reden können, bevor irgendwelche Schnellschüsse passieren?

Mein Lösungsansatz wäre folgender:

• fhem.cfg und das statefile werden nicht mehr gesichert, das parsing der fhem.cfg entfällt
• stattdessen wird die Konfigurationsdatei configDB.conf mitgesichert
• falls als Datenbank sqlite verwendet wird, kann die Datenbankdatei (da es nur ein einziges File ist) natürlich mitgesichert werden. Die Information dazu (Ort und Name der Datei sowie das Datenbankmodell) kann ich Dir aus configDB.pm liefern.
• alles andere wird genau so gesichert wie bisher auch

Hintergrund:

Das Backup einer fhem Installation macht auch völlig ohne die zugehörige Konfiguration durchaus Sinn, z.B. wenn man nach einem Update feststellt, dass sich einige Module nicht mehr so verhält wie man es möchte. Und wenn Du im Forum nachliest, wirst Du sehr schnell feststellen, dass von sehr vielen Usern DIESE Variante der Backupnutzung viel häufiger genutzt wird als zur Wiederherstellung einer Konfigurationsdatei. Es ist deshalb völlig egal, ob die Konfiguration per fhem.cfg oder configDB erfolgt, wichtig ist, dass die "alten" Modulversionen gesichert werden.

Bei der Entwicklung von configDB habe ich darauf geachtet, dass für den Benutzer so wenig wie möglich Änderungen passieren und dass fhem sich weiterhin genau so verhält, wie er es bisher gewohnt war. Ich denke, diesen Grundsatz sollten wir auch beim Thema Backup einhalten, was ich jetzt aber nicht als gegeben ansehe.

Ich hatte Dich um Hilfe gebeten, weil ich gestern aus dem backup-Modul nicht so richtig schlau wurde, wie Du Dir den Backupprozess genau vorgestellt hattest und im Modul auch zu wenig Doku dazu enthalten ist. Ansonsten hätte ich nämlich schon einen Lösungsvorschlag inkl. patch vorschlagen können.

[justme1968]

damit das sichern der sqlite db über das db file zuverlässig funktioniert sollten zu dem zeitpunkt keine db connections offen sein. falls es ein wal file gibt muss das mit gesichert werden.

wenn das backup beim update auch im hintergrund passiert muss natürlich auch die connection  das vordergrund prozesses geschlossen sein.

gruss
  andre

[betateilchen]

Alles richtig, aber es ist viel einfacher. Die Konfigurationsdatenbank ist nur dann geöffnet (= bestehende Verbindung) wenn sie auch benutzt/gebraucht wird, und das ist beim/während des backup nicht der Fall.

[betateilchen]

Das ist eigentich alles, was ich erwartet hatte:

Code Auswählen Erweitern



Index: 98_backup.pm
===================================================================
--- 98_backup.pm (revision 5166)
+++ 98_backup.pm (working copy)
@@ -78,12 +78,24 @@
     }
   }

-  # get pathnames to archiv
-  push @pathname, $configfile;
-  Log 4, "backup include: '$configfile'";
-  $ret = parseConfig($configfile);
-  push @pathname, $statefile;
-  Log 4, "backup include: '$statefile'";
+  if($attr{global}{configfile} eq 'configDB') {
+    # add configDB configuration file
+    push @pathname, 'configDB.conf';
+    Log 4, "backup include: 'configDB.conf'";
+    my ($dbtype,$dbpath) = _cfgDB_backupdata;
+    Log 4, "backup data from configDB: $dbtype - $dbpath";
+    if($dbtype eq 'SQLITE') {
+      push @pathname, $dbpath;
+      Log 4, "backup include: '$dbpath'";
+    }
+  } else {
+    # get pathnames to archiv
+    push @pathname, $configfile;
+    Log 4, "backup include: '$configfile'";
+    $ret = parseConfig($configfile);
+    push @pathname, $statefile;
+    Log 4, "backup include: '$statefile'";
+  }
   $ret = readModpath($modpath,$backupdir);

   # create archiv



ergibt:

Code Auswählen Erweitern



2014-03-09 12:44:45 Global global Backup with command:
tar -cf - configDB.conf /Users/udo/SVN/fhem.55/fhem/configDB.db ./CHANGED ./configDB.conf ./configDB.db ./configDB.pm
./contrib ./COPYING ./demolog ./docs ./FHEM ./fhem.cfg ./fhem.cfg.demo ./fhem.db ./fhem.db.template ./fhem.pl ./HISTORY
./log ./MAINTAINER.txt ./Makefile ./README.SVN ./README_DEMO.txt ./webfrontend ./www
|gzip > ./backup/FHEM-20140309_124445.tar.gz



[rudolfkoenig]

@betateilchen: ich hatte deine Argumente auch alle im Kopf, aber die sind mit so viel wenn und aber verknuepft, dass kein "einfacher" Anwender es verstehen wird oder will. Die, die es verstehen, sind auch in der Lage selbst ein Backup zu erstellen, ist ja keine Hexerei.

Es ist mir auch bewusst, dass man jede Datenbank irgendwie sichern kann (hab selber etliche DB-Backups in perl gebaut), aber ich finde es nicht richtig, dass FHEM per default bei einigen Datenbanktypen was sichert, bei anderen nicht. Es ist eine der "ja, aber"s, was
normale Anwender nicht lesen oder merken.
Statt die DB zu sichern schlage ich vor, dass ihr eine eine Methode fuers Erstellen einer fhem.cfg baut, dieser kann im Backup aufgerufen und damit gesichert werden. Beim Restaurieren verwendet man migrate. Hat den Vorteil, dass es DB-Unabhaengig funktioniert.

Ich hatte Dich um Hilfe gebeten, weil ich gestern aus dem backup-Modul nicht so richtig schlau wurde,

Und ich habe reagiert, weil ich z.Zt den Martin (den Autor) vertrete. Du kannst natuerlich bessere Loesungen vorschlagen, aber ich hielt es wichtig zu reagieren, damit Benutzer keine falschen Hoffnungen machen.

[betateilchen]

@betateilchen: ich hatte deine Argumente auch alle im Kopf, aber die sind mit so viel wenn und aber verknuepft, dass kein "einfacher" Anwender es verstehen wird oder will. Die, die es verstehen, sind auch in der Lage selbst ein Backup zu erstellen, ist ja keine Hexerei.

Da sind keine wenn und aber. Du hast mal wieder einen Weg völlig am Anwender vorbei umgesetzt, obwohl es mit einfachen Mitteln anders (besser) zu lösen gewesen wäre. Einen funktionierenden Vorschlag habe ich oben bereits angefügt.

Statt die DB zu sichern schlage ich vor, dass ihr eine eine Methode fuers Erstellen einer fhem.cfg baut

Nö. Ich betreibe den ganzen Aufwand die fhem.cfg in die Tonne zu treten sicherlich nicht, um mit meinem eigenen Tool dann diesen Schrott wieder zu generieren.
Für SQLITE steht eine einfache Funktion bereits in meinem obigen Vorschlag zur Verfügung (wird einfach mit gesichert) und wer eine andere Datenbank einsetzt, ist - wie Du selbst anmerkst - durchaus in der Lage, seine Datenbank eigenverantwortlich zu sichern. Auf meiner TODO-Liste steht ohnehin noch eine Backup- und Restore-Funktionalität. Das hat aber mit dem fhem-update & backup Prozess nichts zu tun.

ich habe reagiert, weil ich z.Zt den Martin (den Autor) vertrete.

Das war für mich aus dem Modul heraus nicht erkennbar.

kannst natuerlich bessere Loesungen vorschlagen

Das habe ich bereits getan.

[betateilchen]

Statt die DB zu sichern schlage ich vor, dass ihr eine eine Methode ... baut

Mich brauchst Du nicht in der Mehrzahl ansprechen, ich bin nicht der König hier

[rudolfkoenig]

Mich brauchst Du nicht in der Mehrzahl ansprechen, ich bin nicht der König hier (http://forum.fhem.de/Smileys/default/wink.gif)

Sehr originell...
Du bist nicht alleine in der Lage sowas zu bauen, und ich wollte dich nicht direkt mit eine Aufgabe ueberrennen.

Das habe ich bereits getan.

Nach meinem Kommentar

ich finde es nicht richtig, dass FHEM per default bei einigen Datenbanktypen was sichert, bei anderen nicht.

muesste dir auch klar sein, warum mir das nicht passt.

[betateilchen]

Es gibt weder einen Grund, noch eine Notwendigkeit, fhem Benutzer, die mit configDB arbeiten, die Nutzung er standardmäßigen Backupmöglichkeit zu verweigern, wie Du das nach Deinem Kahlschlag jetzt tust.

Ausser vielleicht Deiner Willkür, die für mich inzwischen zwar berechenbar ist, aber deren Sinnhaftigkeit sich mir nie erschließen wird.

Deine Argumentation "für ein Datenbanksystem ist die Sicherung eingebaut, für die andere nicht" zieht für mich nicht. Denn für SQLITE muss ich dafür überhaupt nichts extra einbauen, weil es lediglich eine Datei mehr ist, die bei der Sicherung berücksichtigt wird. Insofern werden MySQL Benutzer nicht durch Nichtimplementation benachteiligt, sondern Sqlite Benutzer profitieren von einem automatisch vorhandenen Vorteil, den dieses Datenbanksystem von Haus aus mitbringt.

Nimm bitte Deine diskriminierenden Änderungen an den beiden Modulen update.pm und backup.pm zurück. Einen funktionierenden Patch, der das beschriebene Grundproblem, nämlich eine Fehlermeldung beim update bzw. backup, beseitigt, hatte ich weiter oben schon gepostet. Nur um diese Fehlermeldungen ging es mir eigentlich.

Über backup- und restore-Strategien der configDB kümmere ich mich schon noch. Darüber musst Du Dir nicht den Kopf zerbrechen, die configDB hat Dich meines Erachtens auch bisher nicht sonderlich interessiert.

[rudolfkoenig]

Auch wenn Du es umformulierst, bleibt es dabei: fuer manche Datenbanken bietet dein Patch eine Sicherung an, fuer andere nicht.
Und nach deine Aussage zu urteilen bist Du auch nicht an einer allgemeingueltigen Loesung interessiert, es reicht, wenn die von dir favorisierte Datenbank abgedeckt ist. Ich kann aber keinem Benutzer zumuten, dass FHEM zwar eine Sicherungsdatei erstellt, aber das was er nirgendwo sonst herunterladen kann (die Konfig) in dieser Sicherung nicht enthalten ist. 

Viele die eine Aenderung haben wollen, sehen nur ihr eigenes Beduerfnis, meine Aufgabe als Maintainer ist, auch an die anderen Benutzer zu denken.

Noch ein Vorschlag, um zu zeigen dass ich nicht bockig bin: Du streichst den Support fuer andere Datenbanken in configDB, dann werde ich dein Patch einbauen (vorausgesetzt es ist getestet und funktioniert).

[betateilchen]

Ich persönlich habe überhaupt kein präferiertes Datenbanksystem. Sqlite finde ich einfach charmant, weil es für die Nutzer das am einfachsten zu nutzende Datenbanksystem ist wäre.

Ich kann aber keinem Benutzer zumuten, dass FHEM zwar eine Sicherungsdatei erstellt, aber das was er nirgendwo sonst herunterladen kann (die Konfig) in dieser Sicherung nicht enthalten ist. 

und ohne die FHEM Konfiguration ein Backup mAn sinnlos ist.

Diese Aussagen können doch nur in Deinem eingefahrenen fhem.cfg-Denken begründet liegen, denn

• Ein fhem ohne fhem.cfg ist in der Tat sinnlos.
• Ein fhem mit configDB lässt sich aber selbst mit komplett fehlender Konfiguration zumindest noch starten und bietet dem Anwender ein nutzbares/vollständig funktionsfähiges Frontend. Insofern macht das Sichern des gesamten fhem (wie bisher) selbst ohne eine enthaltene Konfigurationsdatenbank durchaus Sinn.

Ich schlage vor, wie entfernen die automatische Sicherung im Falle von SQLITE einfach durch Änderung des patches wie folgt:

Code Auswählen Erweitern



Index: 98_backup.pm
===================================================================
--- 98_backup.pm (revision 5166)
+++ 98_backup.pm (working copy)
@@ -78,12 +78,24 @@
     }
   }

-  # get pathnames to archiv
-  push @pathname, $configfile;
-  Log 4, "backup include: '$configfile'";
-  $ret = parseConfig($configfile);
-  push @pathname, $statefile;
-  Log 4, "backup include: '$statefile'";
+  if($attr{global}{configfile} eq 'configDB') {
+    # add configDB configuration file
+    push @pathname, 'configDB.conf';
+    Log 4, "backup include: 'configDB.conf'";
+   # my ($dbtype,$dbpath) = _cfgDB_backupdata;
+   # Log 4, "backup data from configDB: $dbtype - $dbpath";
+   # if($dbtype eq 'SQLITE') {
+   #   push @pathname, $dbpath;
+   #   Log 4, "backup include: '$dbpath'";
+   # }
+  } else {
+    # get pathnames to archiv
+    push @pathname, $configfile;
+    Log 4, "backup include: '$configfile'";
+    $ret = parseConfig($configfile);
+    push @pathname, $statefile;
+    Log 4, "backup include: '$statefile'";
+  }
   $ret = readModpath($modpath,$backupdir);

   # create archiv



Damit werden wieder alle unterstützten Datenbanksystem gleich schlecht behandelt.

Warum hast Du Dir eigentlich im Falle "Datenbanknutzung für DbLog" noch nie solche Gedanken gemacht?

[rudolfkoenig]

fhem mit configDB lässt sich aber selbst mit komplett fehlender Konfiguration zumindest noch starten

Das kann ich nicht nachvollziehen. Vmtl. gehst du davon aus, dass die DB mit der Konfig nicht kaputt ist, das zaehlt aber nicht.

Ich schlage vor, wie entfernen die automatische Sicherung im Falle von SQLITE einfach durch Änderung des patches wie folgt:

Damit hat aber der configDB Benutzer eine Sicherungsdatei ohne Sicherung der Konfiguration, das ist fuer mich aber sinnlos.

[betateilchen]

Rudi, zum wievielten Male soll ich es noch erklären?

Auch wenn Du es nicht nachvollziehen kannst: ein per Backup gesichertes fhem, das mit configDB arbeitet, lässt sich tatsächlich ohne jeglichen Inhalt in der Konfigurationsdatenbank starten und nutzen. Ob dabei mit sqlite, mysql oder postgresql gearbeitet wird, ist völlig belanglos.

Genau deshalb möchte ich den backup-Befehl genau so nutzbar haben wie bisher, nur ohne die Fehlermeldung, die darauf beruht, dass das Schlüsselwort "configDB" in $attr{global}{configfile} eben keine tatsächlich zu sichernde Datei ist. Nichts anderes macht mein vorgeschlagener Patch: Er vermeidet den Versuch, "configDB" als Datei sichern zu wollen.

[betateilchen]

*stups*

[rudolfkoenig]

Es gibt nix zum stupsen. Du ignorierst, dass ich ein Backup ohne Konfig als sinnlos erachte, und hast schon zwei komplett unterschiedliche Vorschlaege ausgeschlagen. Mehr faellt mir nicht ein, bzw. ich will meine Zeit produktiver nutzen.