DBLog - Spalte mit Attribut "alias"

MKeY · 31 März 2019, 11:15:25

Ist es möglich beim Loggen eine Spalte mit dem Attribut "alias" hinzuzufügen? Oder gehen nur Internals (DEVICE, TYPE, ...)?

betateilchen · 31 März 2019, 11:25:43

macht keinen Sinn.

MKeY · 31 März 2019, 19:05:03

Naja, ich nutze die Daten für Grafana und würde dort bei der Darstellung lieber den Alias anstelle meines FHEM Device Namens bevorzugen.
Wüsste nicht, was so schwer daran ist, noch den Alias mit ins DBLog schreiben zu können.

DS_Starter · 31 März 2019, 20:32:33

ZitatWüsste nicht, was so schwer daran ist, noch den Alias mit ins DBLog schreiben zu können.

Eigentlich nichts, außer dass du dafür die Struktur der Tabellen anpasst und das Modul so umschreibst dass diese Strukturänderung nicht zwangsläufig auch durch alle anderen mindestens ca. 1800 User ebenfalls vorgenommen werden muß um kompatibel zu bleiben.

Allerdings habe ich bis dato ein paar Ideen für einen DbLog-Nachfolger gesammelt. Die flexible Adaption der Tabellenstruktur und der zu speichernden Felder gehört auch dazu. Wann ich allerdings dazu kommen werde einen Nachfolger zu erstellen ist offen und es wird dann auch nur ein Modul für MySQL/MariaDB sein und nicht für alle drei DB-Typen wie sie DbLog derzeit unterstützt.
In dem jetzigen DbLog-Modul habe ich nicht vor eine solche Möglichkeit zu implementieren.

MKeY · 31 März 2019, 20:56:57

oki, danke für die info.
ich werde den "umweg" über grafana gehen und dort 11 queries statt einer sammelquery zu machen. Macht auch keinen Aufwand

betateilchen · 31 März 2019, 21:28:51

Zitat von: DS_Starter am 31 März 2019, 20:32:33
Wann ich allerdings dazu kommen werde einen Nachfolger zu erstellen ist offen und es wird dann auch nur ein Modul für MySQL/MariaDB sein und nicht für alle drei DB-Typen wie sie DbLog derzeit unterstützt.

Das ist aber eine ~~blöde~~ unsinnige Idee, nur noch einen Datenbanktypen unterstützen zu wollen. Und dann ausgerechnet mySQL? Warum? Sqlite ist eine Datenbank, die auf jeder Plattform völlig simpel zu installieren ist und auch von jedem Anfänger bewältigt werden kann.

Und wenn Du das Ding schon neu machst, dann mach doch bitte gleich eine echte No-SQL-Datenbank daraus, dann kann man sich vieles "drumrum" vereinfachen. Und auch solche Sonderlocken, wie das Loggen von Attributen, was ich für völlig sinnfrei halte, können dann relativ problemlos umgesetzt werden, ohne Kompatibilitätsprobleme zu verursachen.

DS_Starter · 31 März 2019, 21:40:24

Hallo Udo,

bitte nicht falsch verstehen. Ich habe nicht vor DbLog zu ersetzen, sondern weiterhin genauso wie jetzt zu maintainen.
Was ich mir allerdings vorgenommen habe ist ein (M)DbLog als Nachfolger/Weiterentwicklung zu entwerfen das flexibler bezüglich der Struktur ist und so dem Nutzer ermöglicht weitere Felder als den Standard zu speichern. Ob das ein Attributwert ist oder ein Feld zu Partitionierung beispielsweise soll dabei dem User selbst vorbehalten sein.
No-SQL ist auch ein Thema und wenn ich es hinbekomme diese unterschiedlichen Technologien in einem gemeinsamen Modul zu "verheiraten" um so besser.
Ich bin bei allem noch in der Findungsphase. Wie gesagt, momentan auch nicht akut aktuell.

justme1968 · 01 April 2019, 09:53:49

ich plädiere auch dafür bei einer neu entwicklung vor allem sqlite und no-sql im blick zu haben. und wenn es ,grösser' sein muss postgres nicht zu vergessen.

betateilchen · 01 April 2019, 10:26:39

und HANA ... *duck-und-weg*

justme1968 · 01 April 2019, 10:29:24

lach. da hab ich nur drauf gewartet

DS_Starter · 01 April 2019, 10:33:51

Hi Andre,

na ich denke ich werde mal einen neuen Thread aufmachen um Ideen für ein DbLog Next Generation zu sammeln und zu diskutieren. Die Merkmale und das Software Design wären mir wichtig.
Und betateilchen wird lachen ... SAP HANA hatte ich tatsächlich mal kurz im Kopf, aber die braucht mW. auch in der freien Testversion mindestens 16 Gb RAM

Eine Idee die ich hätte, wäre zum Beispiel die Applikationsschicht und die DB-Schicht zu trennen. D.h. die Appl Schicht sorgt nur dafür geloggte Daten in einen Cache zu schreiben. Die DB Schicht holt sich diese Daten und schreibt sie weg. Stichwort Subprozess. Dann wäre es recht einfach verschiedenste Datenbanken zu bedienen indem man einfach einen anderen spezifische Datenbank API darunter legt. Das wäre ein ähnliches Prinzip wie es Cooltux mit Weather getan hat.
Ich persönlich bin ja ein bekennender MySQL Fan. Aber dadurch sollen die anderen DB Typen nicht benachteiligt werden.

Wie gesagt, momentan habe ich noch andere Dinge vor und ganz wichtig ist das Statement dass das aktuelle DbLog weiter laufen und weiter gepflegt wird, es sei denn es wird irgendwann von selbst durch ein Neues Modul obsolet.
Aber ich denke das alles sprengt den Rahmen dieses Threads.

LG,
Heiko

betateilchen · 01 April 2019, 10:38:12

Zitat von: DS_Starter am 01 April 2019, 10:33:51
D.h. die Appl Schicht sorgt nur dafür geloggte Daten in einen Cache zu schreiben. Die DB Schicht holt sich diese Daten und schreibt sie weg. Stichwort Subprozess. Dann wäre es recht einfach verschiedenste Datenbanken zu bedienen indem man einfach einen anderen spezifische Datenbank API darunter legt.

äh... die unterschiedlichen Datenbankmodelle sind doch in perl schon getrennt. Dieses Rad musst Du nicht nochmal neu erfinden. Und HANA ist eigentlich auch nicht schwierig, im einfachsten Fall kann man die Datenbank über eine ODBC Schnittstelle verwenden.

DS_Starter · 01 April 2019, 10:49:15

ja, das stimmt natürlich. Mir ging es eher um solche Dinge wie das einfache Anlegen und evtl. auch verwalten der DB Strukturen. Ich wollte gerne von dem Config-File weg und in die Applikation übernehmen. Und es gibt da bestimmt noch weitere Dinge in denen sich das Handling der Db Typen unterscheidet. Aber vllt. wird es auch gar nicht soviel anders, mal schauen....

Und HANA können wir auch gerne weiter verfolgen ...ist ja gerade in aller Munde.