Review Database Plugin

[aschwith]

Hallo Freunde des Database Plugins,

ich würde mir gerne mit Euch zusammen einige Codestellen des Database plugins anschauen, bei denen ich vermute, dass dort noch Verbesserungspotential besteht.

Los geht es mir diesem Abschnitt in der Methode _fetch_log:

duration_now = "COALESCE(duration, :inow - time)"

# Duration calculation (S=Start, E=End):
duration = (
"("
# ----------|<--------------------------->|---------->
# 1. Duration for items within the given start/end range
# -----------------[S]======[E]---------------------->
"COALESCE(duration * (time >= :time_start) * (time + duration <= :time_end), 0) + "
# 2. Duration for items partially before start but ends after start
# -----[S]======[E]---------------------------------->
"COALESCE(duration / duration * (time + duration - :time_start) * (time < :time_start) * (time + duration >= :time_start), 0) + "
# ----------------------------------[S]======[E]----->
# 3. Duration for items partially after end but starts before end
"COALESCE(duration_now / duration_now * (:time_end - time) * (time + duration_now >= :time_end), 0)"
")"
)

[aschwith]

Folgende Fragen an die Community:

a) Was ist der Unterschied zwischen duration und duration_now? Duration_now ist identisch duration, es sei denn dration is None. Dann wird duration_now als inow - time berechnet. Dies ist im Allgemeinen immer der Fall fü den letzten DB Eintrag, da dort die Duration noch nicht berechnet worden ist und damit auf None steht.

Frage: Wieso wird in der nachfolgenden Fallunterscheidung nicht immer die duration_now verwendet?

b) Was ist der Zweck von "duration / duration" bzw. "duration_now / duration_now" in den Fallunterscheidungen 2 und 3?
Ok, der Zweck scheint zu sein, hiermit auf ein None in duration bzw. duration_now zu reagieren und dieses dann durch COALESCE abzufangen. Passt für mich.

Diese beiden Punkte erstmal zum Start. Ich meine, die Fallunterscheidungen 1,2 und 3 sind noch nicht vollständig, dazu aber später mehr.
VG

[aschwith]

c) Vollständigkeit der Fallunterscheidungen:

S = Startzeit des Wertes in der DB = time
E = Endzeit des Wertes in der DB = time + duration
time_start = Startzeit des Abfragezeitpunktes
time_end = Endzeit des Abfragezeitpunktes

Fall 1:

S > time_start
E < time_end

Passt aus meiner Sicht, solange wir sicherstellen können, dass durations nie negativ sind und die Abfragezeitpunkte kausal sind, d.h. time_end > time_start. Wir letzteres irgendwo voher überpürft? Falls nicht, sollten wir die Bedingung hier im Fall 1 mit aufnehmen.

[aschwith]

Fall 2:

S < time_start
E > time_start

Hier fehlt meiner Meinung nach die Abfragen, ob E > time_end ist. Für genau diesen Fall müsste die duration dann als duration = time_end - time_start berechnet werden.Geht ihr da mit?

[bmx]

Zu allen diesen Fragen wäre es sinnvoll sich mit dem Ersteller des Plugins blubbs99 sowie Msinn und ggf. psilo auseinanderzusetzen.

[psilo]

ich schaue mir das in ruhe heute nachmittag mal an.. zu den ganzen werten muss ich aber auch reverse engineering betreiben. mein unwissen war für mich auch immer ein hindernis, da irgendwas weiterzuentwickeln. daher super, wenn wir das in der community diskutieren!

ich glaube auch blubbs99 hat hier viel nur aus sqlite übernommen.

[psilo]

schaffs heute doch nicht, behalte es aber auf der agenda :-( hoffe morgen oder samstag kann ich die punkte mal ansehen.

[bmx]

Pushen wir das hier noch mal ...