mySQL Handling of missing id and/or duplicate keys

[tp1de]

Bei Benutzung von mySQL / MariaDB fallen zwei Verbesserungsmöglichkeiten auf.

Die sendTo "getHistory" Funktion gibt einen Fehler im Protokoll aus, wenn noch kein State geschrieben wurde. Dann wird kein ID-Record gefunden. Besser wäre es , wenn entweder die ID bereits beim Aktivieren der Datenfortschreibung erfolgt bzw. beim Aufruf der Funktion "enableState" im Script/Adapter. Alternativ sollte der Fehler im Protokoll unterdrückt werden.

Die sendto "storeState" Funktion erlaubt für mySQL kein Handling von "duplicate keys". InfluxDB oder History erlauben den "storeState" problemlos und updaten ggfs. den Wert. Es wäre wünschenswert das auch für mySQL / MariaDB zu erlauben: INSERT INTO ..... VALUES " .... ON DUPLICATE KEY UPDATE .....

[Apollon77]

Alternativ sollte der Fehler im Protokoll unterdrückt werden.

Nein der ist absichtlich da, damit man zb konfigurationsfehler in Charts oder Widgets erkennt, weil das wäre ein zweiter Fall für solche einen Fehler.

erlaubt für mySQL kein Handling von "duplicate keys"

Das es bei influxdb geht ist zufall, bei history vermute ich das die daten sogar doppelt in der DB existieren und somti auch nichts behandelt wird.

StoreState ist daraus ausgelegt das Daten so behandelt werden als wenn sie vom system genriert wurden wären. bei sql heisst das. "zweiten wert mit 1ms später schreiben"

[tp1de]

Lass mich bitte nochmal kommentieren:

In meinem Adapter lese ich historische Energieverbrauchsdaten, welche ich zur grafischen Darstellung mit Flot in die Datenbank einfüge.. Die getHistory und storeState Funktionen sind ideal, weil unabhängig von der Datenbank (mySQL, InfluxDB, History ...). Es wäre gut wenn

• die getHistory keine Protokollfehler produziert, wenn keine Einträge vorhanden sind (mySQL)
• die storeState das Überschreiben vorhandener Werte erlauben würde

Aktuell muss ich das im Adapter abfragen bzw. SQL mit INSERT INTO ..... VALUES " .... ON DUPLICATE KEY UPDATE realisieren (nur für mySQL/MariaDB).

[Apollon77]

@tp1de Ok damit ichs verstehe:

1.) Ist nur relevant wenn der state neu angelegt wurde. wie oft passiert das? Warum ist es relevant das da nichts im Log steht? Kannst Du das oben genannte reasoning verstehen? Das Loglevel könnte man auf warn setzen ... ok ... aber passiert es echt so oft bei dir? Warum fragst Du überhaupt states ab die keine Wert haben?

2.) Zum "Ändern" (aka überschreiben) von werten gibt es eigene Messages wie "update", dfür ist storeState einfach nicht gedacht und das jetzt da einzubauen macht es für andere User wieder "falsch".

[tp1de]

@Apollon77 Mir geht es im Wesentlichen darum, dass der Adapter unterschiedliche Datenbanken unterstützt und keine "unnötigen" Warnungen / Errors im Protokoll produziert. Mir werden die Fragen / Anmerkungen der Anwender zuviel .....

Zu 1: Ich lege im Adapter States an und enable einige davon für Statistiken im Adapter. Dazu werden stündliche / tägliche Reihen mit getHistory gelesen. Sollte der Adapter gestartet werden, ohne das bisher Daten gelesen werden konnte, dann gibt es die Fehlermeldung im Protokoll mit getHistory, dass die ID fehlt. Das würde ich gerne unterdrücken, bzw. ich frage mich warum die ID nicht beim enable bereits angelegt wird. Das tritt nur by mySQL auf! Warum nicht einfach ein leeres Array zurückgeben?

Zu 2: Ich lese Statistiken über mehrere Jahre / Monate / Tage / Stunden und schreibe diese mit storeState in die Datenbanken. Das erfolgt stündlich. Ein "await adapter.sendToAsync" zum Löschen funktioniert nicht, da ohne mindestens 2-5 Sekunden Wartezeit duplicate keys beim neuen Insert auftreten. Für mySQL mache ich das jetzt mit INSERT INTO ..... VALUES " .... ON DUPLICATE KEY UPDATE, InfluxDB und History funktionieren direkt mit storeState, ohne dass ich doppelte Einträge entdeckt habe. Ich dachte mir, es wäre "schön" wenn der Adapter-Code unabhängig von der ausgewählten Datenbank wäre. Aber wenn ich der Einzige bin ....