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.
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
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.
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
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
eingecheckt.
LG,
Heiko
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
Danke dass das ausgiebig getestet und dann übernommen wurde!
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
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;
thx