98_autocreate - :CURRENT beim automatischen Anlegen von SVG entfernen

[betateilchen]

Da 93_DbLog mit dem Zusatz ":CURRENT" nichts mehr anfangen kann (es gab neulich eine diesbezügiche Änderung im Modul), und ohnehin immer aus :HISTORY gelesen wird, kommt derzeit bei jedem get() auf die DbLog ein Hinweis aus DbLog, dass man seine SVG Definiton ändern soll. (Funktionieren tut das Plotten derzeit trotzdem noch). Da viele SVG-Definitionen vermutlich von autocreate angelegt werden und dort immer :CURRENT verwendet wird, stellt sich die Frage, ob :CURRENT überhaupt noch irgendwo gebraucht wird oder ob das Verhalten bei der Anlage so modifiziert werden kann, dass keine Usereingriffe mehr nötig sind.

Für mich ist das ein Relikt vermutlich aus der Zeit, als DbLog zusätzlich zu FileLog eingeführt wurde, um zu unterscheiden, aus welcher Datenbanktabelle gelesen werden soll. Inwischen stellt sich diese Auswahl nicht mehr. Deshalb die Frage, ob sich das :CURRENT einfach aus der autocreate für SVG entfernen läßt und dieser Parameter einfach komplett entfallen kann. 93_DbLog wird immer mit :HISTORY arbeiten, wenn dieser Parameter beim Aufruf von get() fehlt. Soweit ich gesehen habe, macht auch 92_FileLog keine Unterscheidung nach CURRENT und HISTORY

Insofern halte ich die Angabe dieses Parameters bei der Anlage von SVG-plots für obsolet.

Habe ich etwas übersehen?

[rudolfkoenig]

CURRENT wird in SVG.pm benutzt (aber nur bei FileLogs), ist auch hinreichend dokumentiert.

Ich habe schon angefangen CURRENT mit dem Leerstring zu ersetzen, es macht aber viel Arbeit, und weiss nicht, ob DbLog damit happy ist, deswegen habe ich es wieder zurueckgedreht. Weiterhin waere die Doku anzupassen, und das ist mit Leerstring deutlich komischer zu beschreiben.

Ich finde es ist deutlich einfacher, wenn DbLog CURRENT ignoriert, oder sinnvoll interpretiert.

[betateilchen]

Ich finde es ist deutlich einfacher, wenn DbLog CURRENT ignoriert, oder sinnvoll interpretiert.

Das wird ja momentan gemacht, aber mit dieser Lösung ist Tobias auch nicht glücklich und die DbLog Anwender werden mit diesbezüglichen Hinweismeldungen im Log zugeschüttet.

Du sagst SVG benutzt :CURRENT für FileLog - ok. Aber wer oder was benutzt denn FileLog mit :HISTORY? Man braucht doch für SVG eigentlich beides nicht mehr, irgendwie versteh ich es noch nicht ganz.

SVG ruft FileLog auf => FileLog arbeitet mit CURRENT.
SVG ruft DbLog auf => DbLog arbeitet mit HISTORY.

Den Fall "SVG ruft FileLog mit HISTORY" auf gibts doch gar nicht. Eigentlich ist damit doch alles auch dann eindeutig, wenn der Parameter nicht in der SVG-Definition vorhanden ist? Wo ist mein Denkfehler?

Und einen nichtvorhandenen Parameter nicht dokumentieren zu müssen, kann doch eigentlich auch nicht so schlimm sein

[rudolfkoenig]

Fuer FileLog gibt man entweder den konkrete Dateinamen an oder CURRENT. Die Moeglichkeit die Datei zu spezifizieren finde ich wichtig, auch wenn FileLog_Get bei Angabe von CURRENT den Dateinamen zu raten versucht.

[betateilchen]

wie dem auch sei.

Das derzeitige Zusammenspiel zwischen autocreate, SVG, FileLog und DbLog ist im Moment jedenfalls irgendwie "unbefriedigend".

Eine von autocreate angelegte Definition muss im Nachhinein manuell bearbeitet werden, damit DbLog zufrieden ist.
FileLog braucht einen Parameter, um die Unterscheidung zu einem Dateinamen durchführen zu können, ok. Könnte FileLog nicht auch anhand ":HISTORY" (oder meinetwegen anhand von (:HISTORY || :CURRENT) diese Unterscheidung treffen? Dann könnte autocreate zukünftig wieder eine Definition erzeugen, die für beide Loggingmodule funktioniert und die bisherigen Defintionen würden auch in FileLog weiter funktionieren.

[rudolfkoenig]

Die Unterscheidung ist CURRENT oder <DateiName>, HISTORY ist sicher keine verstaendliche Alternative.
Wenn DbLog-SVG eh nur mit HISTORY richtig Funktioniert, wieso beachtet DbLog-Get diesen Parameter?
Und warum soll ich 3 Module (autocreate/SVG/FileLog) anpassen, anstatt Tobias den einen DbLog.
Zu guter letzt wird FileLog laut Statistik etwa 20-mal oefters eingesetzt als DbLog, d.h. eine Aenderung in DbLog ist einem in FileLog/etc waere aus dieser Sicht vorzuziehen.

[betateilchen]

Mir ist das eigentlich völlig wurscht

Tobias hat das Problem in "seinem" Modul, nicht ich. Und die User haben das Problem, weil sie permanent mit Hinweisen im Log zugeschüttete werden, die häufig als Fehlermeldung fehlinterpretiert werden, was  dann dazu führt, dass die User wieder eine alte DbLog Version verwenden, was eigentlich auch nicht Sinn und Zweck der Sache ist.