New database plugin: misc issues

[onkelandy]

Reported by @onkelandy:

• query result is None if last log value was written before the query timeframe:
  When querying db('avg','10i','now') and there is no value in the log for that period (just in the item table) the plugin returns a "None"

• query result "avg" is wrong as the last entry in item table is ignored:
  When a boolean item was on for 6 minutes in a row but off the rest of the time during the last hour the query ('avg', '60i') always returns 1.0 instead of 0.1 because the last value, the "0", is only written in the item table. -> resolved with the latest version

• no database entry when value of item is 0:
  When configuring an item to use the database (database=yes) the item in MySQL doesn't get created as long as the item stays 0. Only when turning it on, the item gets created. -> is more a core thing: should items initially get a value or None (because we do not know the current value until it gets change/set)

• database query doesn't seem to work correctly:
  sh.steckdosen.eg.bad_heizung.SA.db('avg','1m','now') returns a value of 0.02 even though the item was turned on for over a minute constantly.
  NOTE: Ouch, did use 5m for 5 minutes not 5i :( Nevertheless there's a problem when getting as zero as result of a query.

• Error on item initialization: 2017-05-10 23:21:08 WARNING Database dump nas_nas Database: problem updating WP.Status.Temperatur.Boileroben: Packet sequence number wrong - got 1 expected 12 -> use lock on database access in parse_item

Reported by @psilo909:

• When quering series for a timerange having no data in the database a TypeError: unorderable types: int() > NoneType() error is logged. -> never occured with the new version

Other issues:

• fix license header - Fix licence header: remove cstrassburg, add ohinckel #178

• create a dump method to dump the whole database (maybe a timerange can be provided to only dump a specific range instead of all since the database could grow a lot over the time)

• provide a delete item method for item removal: this method can be used to completely remove a given item from item and log table (if data exists).

• create a cleanup job: remove all item which are currently not used anymore to keep the database clean (beware of using this in a multi-instance setup since one instance doesn't know items from another one and will remove them).

• lock database while dump running: to avoid errors while dump is running when other quieries were issues to the database the database should create some (short) locks for the dump queries.

• add date-time columns: for the microseconds columns time and changed should also be a date-time column (time_date, changed_date) containing a formatted date string (YYYY-mm-dd hh:ii:ss) - could also contain microsecond part.

• move the database config line from smarthome.conf to the plugins.conf -> can't be moved, since this is DB-API support is core functionality (could be used by other plugins or logics too and is not restricted to be used by the database plugin). -> will be discussed in New database plugin: final architecture #208

• sleep short of time between reconnect try in lib/db.py / Database.verify() - done 1b3ab8f

[ohinckel]

Point 1: yes that's right and the problem here is that the plugin does not know if the current value of an item is the initial value (set by SH while starting up) or a value from a later update. So the value will always be inserted into the database. Other plugins like the sqlite does this too. sqlite_visu2_8 does not have this problem because it always initializes the item with the last value from the database (no configuration option available). This behavour ca be alos be activated in the datbase Plugin by using database = init, which will then not have this problem.

To solve this I suggest to implement one of the following solutions:

• add flag to the item's class which identifies if the item's value is the initial value set by SH while starting up or if the item's value was set by an update (e.g. sh.some.item.is_initial_value()) - alternatively use a NULL/None value for the initial item value on startup instead if keeping this in an additional flag.
• keep a list of items in the plugin directly with the item status if it was already updated or if it has still the initial value (this way not generally solved by item class but only in the plugin)

I would prefer the first implementation in the item class, because it is more generic and other plugins or logics could benefit from this. See also comments in 56cd106

Point 2: I need to have a closer look at this to find out what is wrong here. Can you provide the database data for this item and the timestamp when the result was queried? Could be that the data is not suitable for such a query. Was it a problem with the sqlite_visu2_8 too? Also tried to use on instead of avg?

[Foxi352]

imho i would also prefer the first implementation. But i would vote for the "None" item value as long as none has been set instead of adding yet another property.

[onkelandy]

I guess we can forget the second issue I've been mentioning.. Stupid me :(

Only thing I'm wondering.. If I query a timespan where an item was 0 all the time I don't get a "0" as a result but a None. If I want to use the result for a calculation it actually fails.

[ohinckel]

OK, thanks for clarifying! Maybe the None value is because the database does not contain a value at all? So no rows returned and None will be returned. But this should be the case for the other plugins too.

[onkelandy]

So if I query an item for lets say 60 minutes I do get a correct result. If I query it for the last 10 minutes I might get a None as long as there was no change in the last 10 minutes and the value was 0. Happens mostly with booleans of course, at least with the avg operand.

[onkelandy]

Doch noch ein Problem. Frage ich avg eines booleans der letzten 25 Minuten ab, das vor ca. 20 Minuten für 3 Minuten eingeschaltet war, erhalte ich 1.0

2016-12-01 09:06:15 DEBUG    __init__     databasequery Fetch SELECT ROUND(AVG(val_num * duration) / AVG(duration), 2)FROM log WHERE item_id = :id AND time > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = :id AND time < :time_start) AND time <= :time_end AND time + duration > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = :id AND time < :time_start) (args {'id': 113, 'time_end': 1480579575336, 'time_start': 1480578075335}): ((1.0,),) -- __init__.py:_fetch:385
2016-12-01 09:06:15 INFO     databasequery databasequery Heizung der letzten 25 Minuten: 1.0.  -- databasequery.py:<module>:16

Frage ich für die letzten 15 Minuten ab, wo auch wirklich nichts eingeschaltet war, gibt's das theoretisch korrekte "none"

2016-12-01 09:08:22 DEBUG    __init__     databasequery Fetch SELECT ROUND(AVG(val_num * duration) / AVG(duration), 2)FROM log WHERE item_id = :id AND time > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = :id AND time < :time_start) AND time <= :time_end AND time + duration > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = :id AND time < :time_start) (args {'id': 113, 'time_end': 1480579702085, 'time_start': 1480578802084}): ((None,),) -- __init__.py:_fetch:385
2016-12-01 09:08:22 INFO     databasequery databasequery Heizung der letzten 15 Minuten: None. 

[ohinckel]

This always depends on the data in database. If there are only records matched the time range with value 1 it will always return 1. Listing the database values would help to clarify this.

[onkelandy]

Find attached the database entries. The item got activated at 20.23 and turned off at 20.27
Querying a timeframe that implements the short period where it was turned on (i.e. last hour at 21.00 o'clock) returns 1.0.

In my opinion the avg result for an item that was turned on for 6 minutes in the last hour has to be 0.1 - am i wrong? I get a 0.11 when I query the last 350 minutes.

sql.zip

[ohinckel]

It seems that the off at 20:27 is not dumped to the database - at least your SQL file does only contain a value for 19:54 and 20:23, but missing 20:27. I guess the off was the last item change, which will only be dumped to the database on the next item change. The database contains all item values except the last/current one (because it's not clear, how long this item will be on the current value to fill up the duration field in the database).

[ohinckel]

But i would vote for the "None" item value as long as none has been set instead of adding
yet another property.

What do the other think about this idea setting all items initially to None when SH.py starts up? Of course, this will not affect the cached values (e.g. when using cache = yes or SQLite/Database plugins's init setting, etc). Only these items have initially no value at all, will be set to None.

@cstrassburg, do you have any opinion about this?

[onkelandy]

The "off" was the last change and is put in the item table. The duration of the last "on" entry is correctly written in the database as 213159ms = 3,5 minutes (20.23-20.27)

[onkelandy]

I've tried to run the SQL query from 6 posts above directly in phpmyadmin - the result is correct (0.11)! So there has to be some error with interpreting the result..?

SELECT ROUND(AVG(val_num * duration) / AVG(duration), 2)FROM log WHERE item_id = 113 AND time > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = 113 AND time < 1480578075335) AND time <= 1480579575336 AND time + duration > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = 113 AND time < 1480578075335)

-> 0.11

That was the query from the plugin (exactly the same but wrong result):

2016-12-01 09:06:15 DEBUG    __init__     databasequery Fetch SELECT ROUND(AVG(val_num * duration) / AVG(duration), 2)FROM log WHERE item_id = :id AND time > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = :id AND time < :time_start) AND time <= :time_end AND time + duration > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = :id AND time < :time_start) (args {'id': 113, 'time_end': 1480579575336, 'time_start': 1480578075335}): ((1.0,),) -- __init__.py:_fetch:385

-> 1.0

[ohinckel]

The mentioned wrong result is from a query for 09:06:15 (in the morning). The data ZIP contains entries for 19:54 and 20:23, but not the value for around 09:06. So it is not possible to check the query and the result. Executing the logged query later/now may return other results because more data could be logged to the database in the meantime.

I bet when the plugin will execute the query again it will also return the "correct" value. But it is impossible to reproduce this since the queries always start from "now" back some time. If you could also provide the data for 09:06 I could check when time columns to find out how the log table looked at this time and manually try to select the data.

[onkelandy]

Hmm, I see. Yes, querying sh.steckdosen.eg.bad_heizung.SA.db('avg', '860i', '840i') now also results in 0.11

Attached is the full log table for the specific boolean item
full_log.zip

[onkelandy]

I guess the problem is that the 0 from the item table gets ignored in the calculation?

[onkelandy]

Ich habe mal die letzten 2 Probleme oben in die Liste eingefügt, hoffe, es ist alles halbwegs verständlich.

[psilo909]

seit dem neuen update ist mein min max avg chart nur noch mit avg linie:

[ohinckel]

Danke dafuer, aber ich denke diese Probleme lassen sich nicht alle loesen:

Punkt 1: das hatte ich schonmal versucht zu loesen und einfach den letzten Wert vor Statzeitpunkt mit zu selektieren. Das hat aber Probleme mit den Charts, die sich per Interval aktualisieren, gemacht (u.a. Zickzacklinien). Ausserden ist es schwierig (vielleicht auch nicht korrekt moeglich) den Wert vor Startzeitpunkt mit in die Selektion auchzunehmen, da man eigentlich nicht weiss, wie man diesen Wert gewichtet in der Selektion beruecksichtigen sollte.

Punkt 2: den aktuellen Wert zu beruecksichtigen ist etwas schwierig, da man den aus der item-Tabelle holen muesste aber noch nicht klar ist fuer welche Dauer das gesetzt bleibt. Man koennte auf "bis jetzt" ausweichen. Alternativ einen Log-Eintrag bei Aenderung in die log-Tabelle schreiben - aber dann mit welcher Duration? So richtig faellt mir da keine schoene Loesung fuer ein... - du mit deinen bool-Items in den Charts; wer macht sowas schon 😉 Dass das vorher bei dir kein Problem war. Muesste mit sqlite aehnlich gewesen sein.

Punkt 3: es werden Aenderungen in die Datenbank geschrieben. Wenn das Item initial auf 0 steht und bleibt, wird auch kein Eintrag geschrieben. Nur dann, wenn es sich aendert. Das ist deswegen so, weil man nicht wiess, ob das der initiale Wert ist oder ein gesetzter Wert. Man koennte hier die Idee mit den None Werten beim Startup aufgreifen. Dann koennte man unterscheiden ob gesetzt oder initial Wert. Mit dem Wert 0 hat das aber nichts zu tun - ist nur fuer num Items der initiale Wert. Gleiches gilt auch fuer andere Typen.

@psilo909 schaue ich mir an, danke fuer's Feedback! Soeben getan, bitte nochmal pruefen.

[psilo909]

noch was, beim rtr chart fehlen wohl auch daten, siehe der sollwert

das war aber vorher schon

[onkelandy]

Heho, Danke für die Antworten..

Das Problem mit den Charts, die mitten drin anfangen, hab ich auch bei beliebigen Items, mit normalen Einträgen in mysql. Läuft ja alles irgendwie darauf hinaus, dass entweder der erste oder letzte Wert nicht in der abgefragten Zeitspanne drin sind und daher die Queries nicht passen.

Vermutlich stelle ich mir das zu simpel vor, aber im Prinzip müsste doch Folgendes klappen:
Nehmen wir eine Query von 9:00 bis 10:00 Uhr an. Folgende Datenbankeinträge:
8:59 -> 0
9:30 -> 1
9:36 -> 2 (momentan nur im item Table, da seither nicht geändert)

Der Wert 1 wird mit seiner Duration von 6 Minuten "normal" in die Abfrage genommen. Selbes gilt für alle anderen Werte innerhalb der Zeitspanne außer dem "Ersten" und "Letzten", die u.U. nicht in der abgefragten Zeit liegen.
Der Wert 0 wird als vorheriger Eintrag ausgelesen, die Duration wird errechnet: erster Eintrag innerhalb der Zeitspanne minus Anfang der Zeitspanne, also 9:30-9:00 = 30 Minuten
Der Wert 2 wird entweder aus dem Item gelesen, oder, ich fände das eigtl. übersichtlicher, auch in den Log geschrieben, da sich der Wert ja geändert hat. Die Duration in der Datenbank bleibt solange "None" bis wieder ein anderer Eintrag dazu kommt. Stattdessen wird die Duration errechnet: Endzeitpunkt der Abfrage minus letzter Logeintrag in der Zeitspanne, also 10:00-9:36 -> 24 Minuten

Wie das Beispiel von psilo zeigt, besteht das Problem übrigens nicht nur bei boolschen Werten, sondern bei ALLEN Items, bei denen die Werte über einen längeren Zeitpunkt konstant bleiben. Also Sollwerte, Lüfterstufen, Lichthelligkeiten, etc. Und ja, die Probleme waren mit sqlite sicher auch da.. ;)

[psilo909]

ich habe seit neustem eine: 2016-12-12 18:05:16 ERROR Main Can not execute query: SELECT MIN(time), MAX(val_num) FROM log WHERE item_id = %s AND time > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = %s AND time < %s) AND time <= %s AND time + duration > (SELECT COALESCE(MAX(time), 0) FROM log WHERE item_id = %s AND time < %s) GROUP BY ROUND(time / %s) None (args [91, 91, 1481475916635, 1481562316636, 91, 1481475916635, 864000]): (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'None' at line 1")

tritt bei meinem plot.period beim heizungsraum auf, bspw
{{ plot.period('eta_unit.boiler.heating_pressure.value_plot_1m', 'eta_unit.boiler.heating_pressure.value', 'max', '1m', '', '', '', '', 'Heizungsdruck', '', 'line', 'Heizungsdruck in bar') }}

muss am max liegen, der avg chart geht

[ohinckel]

Ja, der Fehler sollte bei min/max/on sein, da dort kein order-by in der Abfrage verwendet wird. Das habe ich mit dem letzten Commit in https://github.com/smarthomeNG/plugins/blob/ea1b82199c5579bf1f4073ce2097bf648790ad9e/database/__init__.py#L320 eigentlich korrigiert. Ist das auch dein Stand?

[psilo909]

@ohinckel ne, alles gut jetzt! hatte noch nicht gepulled seitdem die aufräumaktion hier läuft. habe sorge, dass es mir alles zerschiesst und wegen kindergeburtstagen, defekten sektoren auf meinen NAS platten und zahnarztterminen seitdem keine muße gehabt. sorry for that

[onkelandy]

Kann ich noch irgendwas Brauchbares beitragen @ohinckel ? Ist die Problematik nachvollziehbar oder hab das Prob nur ich..?

[psilo909]

gibts was neues zu den "fehlenden" werten? die lücken hatte ich auf sqlite def. nicht

[ohinckel]

@onkelandy nein, soweit schon alles klar. Kann aber nicht so einfach umgesetzt werden, da es sich nicht mit der Query erschlagen laesst, sondern manuell hinterher gerechnet werden muss. Ob es dafuer eine saubere Loesung gibt, weiss ich nicht. Meine vorherige Idee einfach den letzten bzw. den ersten Wert mit zu selektieren hatte zu den zickzack Linenen gefuehrt - allerdings nur bei Chart-Updates. Vielleicht sollte man in diesen Faellen die Abfrage dann ohne ersten/letzten Wert machen, sonst immer mit.

@psilo909 nein, bisher nicht. Ich weiss auch nicht welche Abfragen im rtr angezeigt werden und ob das ein Problem bei der Abfrage oder den Werten ist. Habe es mir bisher noch nicht genauer angeschaut.

[ohinckel]

@psilo909, ich habe jetzt erstmal noch eine dump() Methode in das Plugin eingebaut. Mit dem kann man die Datenbank in eine CSV-Datei dumpen lassen. Einschraenken kann man die Daten auch, z.B. bestimmtes Item, Zeitraum (Start, Ende) - siehe Doku.

[onkelandy]

@ohinckel Könntest vielleicht mal den "alten" Abfragecode hier posten oder einsetzen.. vielleicht könnte man ja übergangsweise mal ne Option im Plugin einbauen, dass man selbst einstellt, ob die Berechnung korrekt sein soll oder die Live-Update-Anzeige. Wäre auf jeden Fall ein paar Tests wert.

Ein gutes Neues!

[ohinckel]

Das Locking ist nun entsprechend erweitert. Aktuell ist es nun in allen Methoden drin, die kein explizites Locking selbst machen (in dem z.B. ein bereits erstellter Cursor uebergeben wird). Auch die cleanup() Methode habe ich noch angepasst.

[onkelandy]

Cool, ich habs mal upgedatet.. momentan scheint alles recht gut zu funktionieren. Davor hat er definitiv nichts in die Datenbank geschrieben, jedenfalls wird im Graph nix angezeigt.

Ich meld mich wenn es News gibt

[psilo909]

Bin nun auch wieder am Testen.. Musste leider die gesamte Bestands-DB droppen.

Kriege mit der Version aus @ohinckel 's branch jetzt sowas hier:

2017-05-22 18:40:12 ERROR Main Item knx_global.weather.wind: problem running <bound method Database.update_item of <plugins.database.Database object at 0x7fa903e4dcf8>>: 'int' object has no attribute 'timetuple'
Traceback (most recent call last):
File "/usr/local/smarthome/lib/item.py", line 714, in __update
method(self, caller, source, dest)
File "/usr/local/smarthome/plugins/database/init.py", line 135, in update_item
start = self._timestamp(item.prev_change())
File "/usr/local/smarthome/plugins/database/init.py", line 571, in _timestamp
return int(time.mktime(dt.timetuple())) * 1000 + int(dt.microsecond / 1000)
AttributeError: 'int' object has no attribute 'timetuple'

[ohinckel]

@psilo909, super, danke dir fuer den Hinweis. Der Fehler hat sich mit dem letzten Umbau eingeschlichen und ist jetzt gefixt. Dafuer gibt es jetzt auch einen Test, damit das nicht nochmal kaputt geht ;-)

[psilo909]

@ohinckel kann bestätigen, dass es jetzt weg ist :) dann beobachte ich mal.. seit gestern hat mich leider eine meiner fritzbox logiken zugespammt, jetzt sieht das log wieder "beobachtbar" leer aus.

[psilo909]

Bisher fehlerfrei, great work!!!

Sollen wir nochmal alle gemeinsam überlegen, wie man das Ganze jetzt doch etwas mehr vom Kern entkoppeln könnte? @cstrassburg war damit ja auch nicht wirklich glücklich

[onkelandy]

Habe soweit auch keine Fehlermeldungen mehr, sieht gut aus, Verbindung läuft stabil. @psilo909 hast du sqlite auch mal probiert?

Ich denke, das Wichtigste wäre mal die config-Zeile aus smarthome.conf raus zu bringen ;)

[psilo909]

@onkelandy nein, ich bin nicht sicher, wie sich das mit der visu verhält, wenn ich beide gleichzeitig an habe?! multiinstance sollte man aber so oder so mal testen

[psilo909]

hmm gerade hatte ich reichlich strange charts auf der übersichtseite (threads etc.).. leider keinen screenshot gemacht, nach f5 drücken wars weg.. ich beobachte.. scheint speziell da zu sein, wo es relativ schnell tickt..

[ohinckel]

Das Ausgliedern kann man in einem neuen Issue diskutieren. Ich finde aber, dass Datenbankunterstuetzung zum Core gehoeren sollte, weil dadurch es auch a) anderen Plugins ermoeglicht wird Datenbanken generell zu unterstuetzen/verwenden, b) es in Logiken eingebunden werden kann, c) alle das gleiche Interface verwenden (verringert Komplexitaet durch Vermeidung des Einsatzes verschiedener Frameworks).

Die Konfiguration im der sh-Konfig ist global zu sehen und definiert nur die allgemein unterstuetzten Datenbanktreiber (egal ob diese in Plugins, Logiken oder sonstwo verwendet werden). Hat mit der eigentlichen Datenbankverbindung erstmal nichts zu tun. Die referenziert nur auf diese konfigurierten Treiber. Das Ganze koennte man aber evtl. noch herausziehen und in die Plugin-Konfig verschieben. Wir sollten aber versuchen die lib/db.py allgemein verwendbar zu lassen damit darauf aufgebaut werden kann.

Der Einsatz beider Plugins (sqlite, database) sollte funktionieren solange man nicht beide Plugins fuer die gleichen Items definiert.

[psilo909]

@ohinckel 2ter issue wäre ok für mich.

grundlegend finde ich nur, dass die entscheidung dann alle tragen sollten, also insbes auch @msinn , @bmxp und @cstrassburg.
ich habe auch schon von einigen nutzern gehört, dass sie zumindest die notwendigkeit der konfiguration der db in der globalen .conf datei nicht gut finden.

[psilo909]

also, auch wenn es keinen fehler im log gibt, habe ich folgendes problem:

lasse ich die system-charts ca 1h laufen, sind sie nur noch sehr rudimentär sichtbar und starten offenbar bei einem anderen offset.. drücke ich F5, ist wieder alles ok. könnte schon mit dem plugin zu tun haben, oder?

[psilo909]

gleiches problem übrigens auch bei aktuellen temperaturwerten.. es scheint weiterzuticken aber von dem zeitpunkt an, wo man die visu "offen gelassen" hat. die alten werte scheinen irgendwann einfach zu verschwinden.

[ohinckel]

Koennte schon mit dem Plugin zu tun haben, da dort die series() Methode verwendet wird. Werden die System-Items auch via database Plugin geloggt, oder sind die nicht weiterhin sqlite? Die Temperatur wird vermutlich schon in die Datenbank geloggt.

Kannst du mir evtl. das SmartHome Debug Log geben (fuer Database und Visu Plugin), damit ich mir die Abfragen anschauen kann? Gut waere auch ein entsprechender Auszug der Daten fuer die Items aus der Datenbank.

[psilo909]

alle umgestellt:

[env]
    [[core]]
        [[[version]]]
            type = str
        [[[start]]]
            type = foo
        [[[memory]]]
            type = num
            database@mysqldb = init
        [[[threads]]]
            type = num
            database@mysqldb = init
        [[[garbage]]]
            type = num
            database@mysqldb = init

spannend ist evtl das oberste NULL (beispiel der memory wert)?
Ich glaube aber nicht, dass es an den werten in der DB liegt. wenn ich mit f5 neu lade, ist alles ja wieder ok

[psilo909]

es ist jederzeit reproduzierbar.. einfach die jew items im chart so ~30 min im browser offen lassen. müsste bei dir ggf auch passieren
wenn es bei dir nicht passiert, schalte ich die jew. plugins auf debug um.. aktuell loggen die nur auf error ebene.

[psilo909]

bei komplett geclearten (aber noch ohne werte vorhandenen) tabellen kommt auch noch der hier: 2017-05-29 16:20:32 ERROR Main Can not execute query: SELECT MAX(version) FROM database_version; (args []): (1146, "Table 'smarthome.database_version' doesn't exist")

In dem Fall aus meiner Sicht kein Error. Oder funzt das nur, wenn es auch die Tabellen noch nicht gibt?

[psilo909]

schon versucht mein thema nachzustellen? wenn ich doch mit debug mitloggen soll, bitte nur eine kurze info...

[ohinckel]

2017-05-29 16:20:32 ERROR Main Can not execute query: SELECT MAX(version) FROM database_version; (args []): (1146, "Table 'smarthome.database_version' doesn't exist")

Kein Fehler, sondern nur der Versuch herauszufinden ob es die Versionstabelle schon gibt oder nicht. Ein SELECT ist verbreiteter im SQL-Standard als ein "CREATE TABLE IF NOT EXISTS". Daher die Abfrage die beim der ersten Nutzung des Plugins fehlschlaegt.

In dem Fall aus meiner Sicht kein Error.

Ja, kein Fehler nur unschoen. Ich habe in diesem Fall noch ein INFO-Log eingebaut damit der Benutzer weiss, dass dieser Fehler bei der Erstnutzung ignoriert werden.

Zu den Charts: dafuer habe ich noch einen Fix committed. Weiss aber nicht ob der damit etwas zu tun hat. Auf jeden Fall haben sich vorher die Chart-Update-Zyklen immer verkleinert - das ist korrigiert, die bleiben nun gleich.

[psilo909]

ich finde für den normalen user irritiert es halt als "ERROR".. der denkt da stimmt was nicht.

charts scheinen besser zu sein, muss das morgen aber noch tieferlegen.

[psilo909]

Update: gerade mehrere Stunden die SV offen gelassen - Charts zeigen das Verhalten nicht mehr. Damit haben wir aktuell m.E. keine Bugs mehr. Yippeahh

[ohinckel]

Vielleicht koennen wir die drei offene Punkte aus der Beschreibung noch pruefen:

• avg Selektion falsch, da letzter Wert nich beruecksichtigt wird -> @onkelandy kannst du hier evtl. noch etwas pruefen bzw. dazu sagen?
• Exception mit None type -> @psilo909 soweit ich weiss, gibt es diesen Fehler auch nicht mehr? Also erledigt? Oder muesste man nochmal mit leere DB testen?
• database Items werden erst bei Wertaenderung in die DB geschrieben -> sollten wir die beim Initialisieren anlegen?

[psilo909]

zu 2) @ohinckel ich habe für das vorletzte update die gesamte DB resetted. Es ist nicht mehr aufgetreten

[ohinckel]

Ich habe die Punkte aus der Beschreibung nun alle erledigt. Das einzige was jetzt noch fehlt ist:

• Architekturvorschlaege umsetzen (siehe New database plugin: final architecture #208)
• ein Migrationsskript (sqlite -> database)
• ein Pack-Mechanismus (falls gewuenscht) um die Datenbank "klein" zu halten, (alternativ) eine Archivierungsfunktion
• Dokumentation wie man umsteigen kann (sqlite -> database)

Mein Vorschlag: fuer die einzelnen Sachen nochmal getrennte Issues erstellen, damit diese getrennt voneinander behandelt werden koennen.

Um das hier zum Abschluss zu bringen, wuerde ich einen neuen PR fuer meinen Branch einstellen, den wir dann mergen koennen.

[ohinckel]

Ich schliesse dieses Issue, da nichts weiter offen ist. Ich habe

• ein PR erstellt und
• ein Issue fuer das MIgrationsskipt sowie die Doku dazu und
• ein Issue fuer den Pack-Mechanismus.