DbLog: "on update CURRENT_TIMESTAMP" bei History-Tabelle entfernen

Begonnen von tobox, 15 Februar 2018, 12:58:36

Vorheriges Thema - Nächstes Thema

tobox

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.

DS_Starter

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@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

tobox

Zitat von: DS_Starter am 15 Februar 2018, 13:52:07
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.

DS_Starter

ZitatBei 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.

ZitatIch 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.

ZitatIch 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@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

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@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

JoeALLb

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

tobox

Danke dass das ausgiebig getestet und dann übernommen wurde!


pc1246

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
HP T610
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; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

JoeALLb

Zitat von: pc1246 am 13 März 2018, 11:00:40
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

pc1246

HP T610
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; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly