Autor Thema: DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen  (Gelesen 1221 mal)

Offline tobox

  • Jr. Member
  • **
  • Beiträge: 50
Liebe DbLog-Entwickler,

ich habe mir heute zum zweiten Mal einen Großteil der History zerschossen, weil ich die zur Datenbankpflege einige Einträge geändert habe (konkret: Genauigkeit eines Temperatursensors auf eine Nachkommastelle begrenzt). Anschließend waren alle Datenpunkte verschwunden, weil die History Tabelle bei Änderungen den Timestamp aktualisiert. Ich halte das für sehr fehleranfällig, und sehe keinen Grund, weshalb das bei der History-Tabelle so eingestellt ist. Bei der Current-Tabelle macht es jedoch sinn.

Deswegen möchte ich vorschlagen, in fhem/contrib/dblog/db_create_mysql.sql die history-Tabelle folgendermaßen zu erstellen:

CREATE TABLE history (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(64), READING varchar(32), VALUE varchar(32), UNIT varchar(32));

Spricht was dagegen? Die einzige Änderung ist, dass das automatische aktualisieren des Timestamps bei Updates deaktiviert ist.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3151
Antw:DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen
« Antwort #1 am: 15 Februar 2018, 13:52:07 »
Hallo tobox,

ich werde mal überlegen ob die Empfehlung für alle DBs funktioniert.

Abgesehen davon gibt es im DbRep zur Änderung von Werten changeValue was genau dazu gedacht ist dem User eine Datenänderung abzunehmen und dabei die Timestamp Problematik zu beachten.

LG
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz

Offline tobox

  • Jr. Member
  • **
  • Beiträge: 50
Antw:DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen
« Antwort #2 am: 20 Februar 2018, 16:12:44 »
ich werde mal überlegen ob die Empfehlung für alle DBs funktioniert.

Abgesehen davon gibt es im DbRep zur Änderung von Werten changeValue was genau dazu gedacht ist dem User eine Datenänderung abzunehmen und dabei die Timestamp Problematik zu beachten.

Bei mir läuft es zumindest mit MySQL und MariaDB. Danke für den Hinweis auf DbRep, kannte ich nicht - hätte mir im konkreten Fall aber wohl auch nicht geholfen. Ich habe das Format sämtliche Einträge eines Readings ändern müssen, und mir ist nicht klar, wie ich das mit DbRep hätte erledigen sollen. Außer natürlich mit "sqlCmd" - aber wie verhält sich das denn bezüglich der Timestamps? In der Doku ist z.B. folgendes Beispiel:

     set <name> sqlCmd update history set VALUE='TestVa$$ue$' WHERE VALUE='TestValue'

Ich würde vermuten, dass dabei auch alle Timestamps kaputtgeschrieben werden... Sollte man vielleicht in der Doku ändern.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3151
Antw:DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen
« Antwort #3 am: 20 Februar 2018, 16:53:35 »
Zitat
Bei mir läuft es zumindest mit MySQL und MariaDB.
Ja, MySQL/MariaDB ist fast immer ok.  ;)
Problematisch ist oft SQLite. Aber für den speziellen Betrachtungsfall sollte es auch mit dieser DB klappen.
Ich will es nur mal mit allen DBs durchgetestet haben. Oder es gibt weitere User die die Problemfreiheit bestätigen können.

Zitat
Ich habe das Format sämtliche Einträge eines Readings ändern müssen, und mir ist nicht klar, wie ich das mit DbRep hätte erledigen sollen.
Du hast die Möglichkeit den neuen Reading-Wert mit einem Perl-Ausdruck zu erstellen. Damit kannst du z.B. ein split auf den alte Wert anwenden. Zum Beispiel:

set <name> changeValue "12 kWh","{$VALUE,$UNIT = split(" ",$VALUE)}"
# der alte Feldwert "12 kWh" wird in VALUE=12 und UNIT=kWh gesplittet und in den Datenbankfeldern gespeichert

Damit hast du m.M. nach genügend Freiheiten den neuen Wert in Abhängigkeit von Merkmalen des alten Wertes abzuändern.

Zitat
Ich würde vermuten, dass dabei auch alle Timestamps kaputtgeschrieben werden... Sollte man vielleicht in der Doku ändern.
Ja, danke für den Hinweis. Das Beispiel ändere ich ab.

LG,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3151
Antw:DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen
« Antwort #4 am: 21 Februar 2018, 20:44:20 »
Nun habe ich meine Tests mit MySQL, SQLite und PostgreSQL durchgeführt mit positiven Ergebnis.

Die history-Tabelle habe ich dabei so angelegt:

MySQL:

CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));

SQLite:

CREATE TABLE history (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));


PostgreSQL:
CREATE TABLE history (
    "timestamp" timestamp without time zone default CURRENT_TIMESTAMP,
    device character varying(64),
    type character varying(64),
    event character varying(512),
    reading character varying(64),
    value character varying(128),
    unit character varying(32)
);

Ich mache noch ein paar Experimente mit DbRep. Wenn nichts weiter auffallen sollte würde ich die Empfehlung übernehmen und die Scripte in contrib zur DB-Erstellung anpassen.

Grüße
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3151
Antw:DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen
« Antwort #5 am: 22 Februar 2018, 09:43:44 »
eingecheckt.

LG,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, Dashboard (interims)
aktive Mitarbeit:SMAEM, SMAInverter
Kaffeekasse: https://www.paypal.me/HMaaz

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1473
Antw:DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen
« Antwort #6 am: 22 Februar 2018, 11:57:44 »
Hi,

ich begrüße die Änderung da ich das ursprüngliche Verhalten ebenfalls als höchst kritisch betrachte...
jedoch wäre mir
`TIMESTAMP` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',lieber gewesen, da ich eigentlich immer einen Timestamp angeben muss und so zu konsistenteren Ergebnissen (im Fehlerfall) komme...
Aber leider hab ich den Thread erst jetzt über das Changelog fürs einchecken von DbLog gefunden ;-)

Dies nur zur Info, großes Problem sehe ich darin nicht!

sG
Joe

FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline tobox

  • Jr. Member
  • **
  • Beiträge: 50
Danke dass das ausgiebig getestet und dann übernommen wurde!


Offline pc1246

  • Hero Member
  • *****
  • Beiträge: 2416
  • Kein support per PN oder eMail
Moin
Mal so eine Frage als Nicht DB-Experte. Kann man das im nachhinein noch anpassen? Oder muss man die DB neu erstellen?
Gruss Christoph
RasPi2
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; add-on board mit 6 IT-Steckdosen;3 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; KS300; ESA2000; HUE

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1473
Mal so eine Frage als Nicht DB-Experte. Kann man das im nachhinein noch anpassen? Oder muss man die DB neu erstellen?

Selbverständlich.
Beispiel:
ALTER TABLE `history`
CHANGE COLUMN `TIMESTAMP` `TIMESTAMP` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP FIRST;
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline pc1246

  • Hero Member
  • *****
  • Beiträge: 2416
  • Kein support per PN oder eMail
Antw:DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen
« Antwort #10 am: 13 März 2018, 11:11:31 »
thx
RasPi2
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; add-on board mit 6 IT-Steckdosen;3 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; KS300; ESA2000; HUE

 

decade-submarginal