FHEM Forum

Moin,

ich mache hiermit den Vorschlag, die maximale Länge von Attributnamen auf 128 Zeichen zu begrenzen und in FHEM einen Mechanismus zu etablieren, längere Attributnamen mit einer Fehlermeldung zurückzuweisen.

Hintergrund:

Bei der Entwicklung der configDB habe ich seinerzeit eine Feldlänge von maximal 50 Zeichen für Attribute verwendet. Zu dem Zeitpunkt und lange danach war das auch völlig ausreichend.

Durch die gesamte MQTT Entwicklung mit ihren unzähligen Automatismen, die den Anwendern das Denken abnehmen soll, kommt es inzwischen zu Attributnamen wie

subscribeReading_Schadstoffe_Entsorgungstermine_2018_description

was über 60 Zeichen lang ist und somit nicht mehr in das vorgesehene Feld der Datenbanktabelle passt. Davon sind 17 Zeichen schon alleine durch das völlig sinnlos lange präfix "subscribeReading_" verplempert.

Die Feldlänge in der configDB werde ich nun auf 128 Zeichen erweitern. Es wäre schön, wenn diese Grenze als Maximallänge für Attributnamen festgeschrieben werden könnte.

Ich unterstütze diesen Vorschlag. Ich bin sogar dafür das auf 50 Zeichen zu begrenzen und halte die schon für zu viel.

Ich bin auch dafür. Würde hier auch 50 Zeichen bevorzugen. Alternativ kann man noch über 64 nach denken, aber mehr nicht.

Meine Stimme für 64...
Gruß,
   Thorsten

Prinzipiell ist mir egal, wie lang das Feld ist, die Überprüfung der Länge (gegen DB-Länge) halte ich aber für sehr sinnvoll (und selbst 50 Zeichen sind in der Darstellung schon eher bescheiden)


Kurz, weil mobil

die attribut länge zu begrenzen finde ich gut. ich würde 64 zeichen vorschlagen.

eine db zu verwenden bei der man die feld längen vorgeben muss allerdings nicht. in einer halbwegs modernen db ist varchar nicht weniger effizient als char. auch sollte eine db keine künstlichen beschränkungen einführen die vorher nicht definiert waren. was wird immer und im jeden fall irgendwann probleme machen. aber das sind zwei ganz andere diskussionen :)

Zitat von: justme1968 am 16 Februar 2019, 21:14:01
in einer halbwegs modernen db ist varchar nicht weniger effizient als char.

Auch bei varchar ist ein Feld nicht unbegrenzt lang - selbst bei modernen Datenbanken nicht.
Aber darum soll es hier jetzt nicht gehen.

bei postgres ist es 1gb und sogar mysql 16byte. beides ist so gross das es mit einem attribut namen nicht wirklich realistisch zu übertreffen ist.

ausserdem ist es dann keine künstliche grenze sondern so wie filenamen längen oder maximale file größe eine beschränkung der plattform und durch ändern der plattform zu umgehen.

Bei Oracle 11g ist ein varchar Feld maximal 4000 Zeichen lang. Ok, das würde vermutlich für einen sinnlos langen Attributnamen schon ausreichen.

Zitat von: justme1968 am 16 Februar 2019, 21:24:40
eine beschränkung der plattform und durch ändern der plattform zu umgehen.

Das ist wohl richtig. Aber leider hat man sich bei FHEM irgendwann dazu entschieden, mehrere Datenbankplattformen zu unterstützen.
Das Feld in der configDB, um das es aktuell geht, ist übrigens schon von Anfang an als varchar(50) definiert. Bei sqlite gibt es damit keine Probleme, weil dort solche Längenangaben einfach ignoriert werden.
Das aktuell beschriebene "Problem" trat bei einem Wechsel von sqlite zu mysql auf, weil dann plötzlich ein Feldinhalt importiert werden sollte, der zu lang war.

Aber das grundlegende Anliegen in diesem Thread ist weniger eine technische Frage, sondern vor allem auch die Frage nach der Sinnhaftigkeit solcher überlangen Attributnamen.
Und in diesem Punkt sind wir uns ja zumindest einig :)

Gibt es das gleiche Problem auch mit dem Readings?

Die Länge der readingNames ist bei der configDB nicht relevant. Aber Deine durchaus berechtigte Frage sollte der DbLog Maintainer beantworten, denn dort werden auch die readings zerlegt und die Namen in Datenbankfelder geschrieben.

Die Frage der Sinnhaftigkeit eines überlangen readingName würde ich allerdings ebenfalls mit "ja" beantworten.

ZitatDie Länge der readingNames ist bei der configDB nicht relevant.

Bedeutet das, dass das statefile prinzipiell anders gespeichert wird, als configfile?

Da readingNamen in manchen Modulen automatisch generiert werden, gibt es vmtl. Probleme beim kuerzen.
Da ich die Aufregegung nur einmal erleben will, wuerde ich beide (Attribut und Reading Namenslaenge) beschraenken, auf 64 Zeichen.
Gegenargumente?

Mach doch mit Ansage und etwas Vorlauf

Zitat von: rudolfkoenig am 16 Februar 2019, 23:12:59
Bedeutet das, dass das statefile prinzipiell anders gespeichert wird, als configfile?

Ja. Technisch betrachtet, ist das statefile für den Betrieb (insbesondere den Start) von FHEM unwichtig. Deshalb wird es beispielsweise auch nicht versioniert.

Zitat von: rudolfkoenig am 16 Februar 2019, 23:12:59
Da ich die Aufregegung nur einmal erleben will, wuerde ich beide (Attribut und Reading Namenslaenge) beschraenken, auf 64 Zeichen.

***gefällt mir***

Jörgs Vorschlag mit der Vorlaufzeit finde ich auch gut.


Es gibt - theoretisch - noch einen dritten Kandidaten: das Internal TYPE sollte sich bitte auch an die jetzt angedachte Begrenzung halten.
Wobei es bisher kein Modul gibt, das einen so langen TYPE verwendet.

Ich bin voll und ganz dafür.
Attributsnamen, Readingsnamen und gerne auch TYPE auf max 64 Zeichen begrenzen. Ist in meinen Augen vernünftig.

Grüße und schönen Sonntag Euch.

Mein Vorschlag wäre eine variable Grenze, bei der die Namensunterscheidung recht weit vorne möglich ist.
Wenn z.B. 64 festgelegt wird, dann ist das für Oracle (dort weis ich es, auch wenn Oracle nicht auf einem Pi läuft) schon zu groß, denn dort müssen sich Namen in den ersten 30 Zeichen unterscheiden. Man kann also sowieso die Spaltennamen nicht verwenden. Und die Speicherung von Inhalten ist bei den meisten DB's als variable Länge sehr effektiv.

Ich würde eine Empfehlung von n Zeichen festlegen, und eine Kürzungsfunktion bereitstellen (habe ich in C fertig).
Befehl eingeben:s_trimName "Hallo-ich-bin-ein-verdammt-langer-name" "-" 40
    -> Hallo-ich-bin-ein-verdammt-langer-name
Befehl eingeben:s_trimName "Hallo-ich-bin-ein-verdammt-langer-name" "-" 30
    -> H-ich-bin-ein-verd-lang-name
Befehl eingeben:s_trimName "Hallo-ich-bin-ein-verdammt-langer-name" "-" 20
    -> H--bin-ein-v-l-nam
Befehl eingeben:s_trimName "Hallo-ich-bin-ein-verdammt-langer-name" "-" 10
    -> H--b--v-l-n

Horst

Ab featurelevel 6.0 wird:
- attr abgelehnt, falls name nicht goodReadingName entspricht
- goodReadingName begrenzt zusaetzlich die Laenge auf 64 Zeichen
Dokumentiert in CHANGED und in UPGRADE.

@Horst: ich gehe davon aus, dass in diesem Fall in configDb nicht um Spalten- oder Variablennamen handelt, sondern um Spalteninhalt, insofern sollte Oracle auch mit mehr als 30 klarkommen.

Bzgl. Kuerzungsfunktion: in ZWave werden fuer die config Attribute einzelner Geraete aus dem openzwave Doku automatisch Attributnamen generiert (ZWave_cleanString), da wird die Laenge auf 32 Zeichen begrenzt, und der Algorithmus versucht beim Wortende abzuschneiden. Um Verwechslung zu vermeiden, wird ein eindeutiger Index angehaengt. Beim Auswaehlen des Attributes wird die urspruengliche Doku eingeblendet, damit man die evtl. unverstaendliche Abkuerzung versteht.

Hallo Rudi,

mit der Längenbegrenzung für Readingnamen könnte/wird es im DbRep Probleme geben.
Die erstellten Readings beim Auslesen von Datenbankinhalten werden zusammengesetzt und sind vom Inhalt der gelesenen Daten abhängig. Ich kann es nicht voraussehen und sind auch nicht sinnvoll zu begrenzen ohne die Funktion zu demontieren.
Bisher war das problemlos. Ein paar Beispiele:


2019-02-18_21-33-43__1__FSM1_Wohnzimmer__trig_eg.wz.wandthermostat.SwitchTr
2019-02-18_21-33-45__1__eg_az_heizkoerperthermostat1_Clima__ValvePosition
2019-02-18_21-33-45__1__eg_az_heizkoerperthermostat1_Clima__boostTime
2019-02-18_21-33-45__1__eg_az_heizkoerperthermostat1_Weather__measured-temp


Es wäre gut wenn die Längenbegrenzung für Readings !  ein ein/ausschaltbares Feature wäre um die Rückwärtskompatibilität zu erhalten. Für Attribute sehe ich keinerlei Probleme.

Grüße,
Heiko

Nach nochmaligem Durchlesen des Threads und einer Nacht drüber schlafen beantrage ich die künstliche Längenbegrenzung für _Readingnamen_ wieder auszubauen bzw. darauf zu verzichten.
Betateilchen hat lediglich ein Problem mit langen _Attributnamen_ in seiner Applikation. Sonst gibt es ebenfalls niemanden der ein Problem mit langen Readingnamen hat bzw.sich technisch bedingt eine Notwendigkeit dafür ergibt.

Diese Namen sind nicht dafuer da, um Daten zu halten, sondern um diesen "Datenspeichern" einen Namen zu geben.
Eine technische Notwendigkeit der Laengenbegrenzung gibt es weder fuer Attribute noch fuer Readings, die DB-Grenzen kann man erhoehen. Ich finde aber auch (wie offensichtlich etliche Andere hier), dass diese Sachen "handhabbar" sein muessen, will sagen, man muss sie sinnvoll darstellen/lesen/schreiben können.

Das Ziel einer sinnvollen Handhabung ist unbestritten, jedoch sollte dieses Ziel nicht durch eine diktatorische Vorgabe erzwungen werden. Im vorliegenden Fall habe ich ja angedeutet, dass eine zwangsweise Beschränkung die Zerschlagung einer funktionierenden Anwendung bedeutet. Sicherlich wird es weitere Beispiele geben.
Und welche Readingslänge als gut handhabbar angesehen wird, damit meine ich vor allem den User der damit umgeht, ist sicherlich sehr subjektiv. Wer will sich anmaßen diese Entscheidung dem User abzunehmen (abgesehen von technischen Zwängen) ?
Mit anderen Worten ... wie krumm darf in Europa eine Gurke sein damit sie in den Laden darf ?

ZitatMit anderen Worten ... wie krumm darf in Europa eine Gurke sein damit sie in den Laden darf ?

Das wurde nach einer Diskussion irgendwo festgelegt, so wie hier auch.
Und es hilft denen, die Gurken weiterverarbeiten, die Geraete/etc zu bauen. So wie hier auch :)

Wie sinnvoll solche Entscheidungen wahrgenommen werden dürfte jedem klar sein.
Ok, dann bitte die Länge auf z.B. 300 Zeichen setzen. Dann dürfte für die nächste Zeit kein Anpassungsbedarf bestehen.
64 halte ich jedenfalls für zu kurz. Warum eigentlich 64 ? Wahrscheinlich weiß es keiner, wieso auch ....

Für sinnvolle (!) reading- und attribut-Namen sollten auch 64 Zeichen durchaus reichen.

Oder wir ersetzen in allen devices alle internals, readings und attributes durch uuid und verzichten komplett auf lesbare Namen. Dann reichen auch die bisher verwendeten 50 Zeichen aus...

*duck-und-weg*

---

Zitat von: DS_Starter am 19 Februar 2019, 15:22:45
Und welche Readingslänge als gut handhabbar angesehen wird, damit meine ich vor allem den User der damit umgeht, ist sicherlich sehr subjektiv.

Dann schau Dir mal eine FHEM Webseite mit Deinen überlangen readings aus DbRep auf einem 12" MacBook oder einem Tablet an. Dann siehst Du sofort, was objektiv "handhabbar" bedeutet.

Sobald ich auf einer Seite im FHEM Frontend anfangen muss, nach links und rechts zu scrollen, läuft irgendwas aus dem Ruder.

Zitat von: DS_Starter am 19 Februar 2019, 15:44:35
Warum eigentlich 64 ? Wahrscheinlich weiß es keiner, wieso auch ....

Weil ...

• 64 mehr ist als 50
• offenbar akzeptiert wird, dass 50 wirklich zu kurz ist
• 64 offenbar hier in der Diskussion mehrheitsfähig ist

Für mich sind das drei gute Gründe, die 64 zu akzeptieren, auch wenn ich im Eingangsbeitrag schon großzügiger war und 128 vorgeschlagen hatte.

Wie gesagt Udo, die Readingsgestaltung im Datenbankfrontend ist ja der Tatsache geschuldet die gelesenen Datensätze der Db in ein Reading umzuwandeln was eindeutig ist. Mir ist klar dass es nicht in jeder erdenklichen Form sich darstellen lässt, liegt in der Natur der Sache. Aber deswegen per se zwangsweise unterbinden halte ich nicht für förderlich.

Ob eine Mehrheit wirklich vorliegt, lässt sich nicht sagen. Dafür war der Zeitraum zu kurz und die Beteiligung zu gering.
Der normale User darf sich hier ja auch nicht äussern.

Jedenfalls möchte ich soviel Zeichenlänge "abringen" wie möglich. Je mehr desto besser. Niemand ist ja gezwungen sie auszunutzen, aber wenigstens nicht unnötig kastriert. Jede festgelegte Länge wird willkürlich sein ...

Es geht einfach um "human readable" und das ist bei 300 Zeichen definitiv nicht mehr der Fall. Auch wenn der Name technisch "logisch" sein mag.

Ich bin ganz bei dir und glaube mir wenn ich behaupte jede Applikation so usable wie möglich zu gestalten, aber manchmal hat das Grenzen. Wenn ich sehe etwas verbessern zu können mache ich es auch ...

Nochmal kurz meine Meinung (ergänzend zu dem was ich oben schon gesagt hatte). Aus "human readable" Sicht ist selbst eine Begrenzung auf 50 oder 64 Zeichen schon zu lang. Aus technischer Sicht gibt es theoretisch keine (sinnvolle) Grenze, es spricht aber vieles dafür, eine Grenze zu haben (und wenn's nur ist, weil manche Datenbanken gerne Grenzen haben). Wichtig ist aber, dass diese Grenze dann auch eingehalten wird, sprich wie Rudi es vorgeschlagen hat, goodReadingName das überprüft. Was spricht daher dagegen, diese künstliche Grenze bei 144 Zeichen (um mal eine andere beliebige Zahl in den Raum zu werfen) oder 288 Zeichen fest zu setzen - Die meisten Entwickler werden schon aus Eigeninteresse vermeiden, auch nur in die Nähe dieser Grenze zu kommen, in Einzelfällen mag dies aber notwendig sein (Lustig wird es dann nur, wenn DBRep versucht ein Reading zu generieren, das aus einem MQTT generierten 288-Zeichen reading kommt :-))

Zitat von: KernSani am 19 Februar 2019, 17:12:08
(Lustig wird es dann nur, wenn DBRep versucht ein Reading zu generieren, das aus einem MQTT generierten 288-Zeichen reading kommt :-))

Genau das ist doch der springende Punkt: Solange Module wie DbRep meinen, sie müssten bestehende readingName nochmal um 23 Zeichen (wenn ich mich nicht verzählt habe) verlängern und dann immer noch gefordert wird, dass auch das neue Reading noch in die Datenbank passt, wird es nie eine "passende" Längenbegrenzung geben. Egal ob 50, 64 oder 288 als Länge festgelegt wird.

M.E. ist einfach das Konzept von DbRep zu überdenken, readingName in dieser Art und Weise zu verändern.

Leider geht die Diskussion allmählich an meinem eigentlichen Anliegen vorbei.

Nochmal zu DbRep. Es werden lange Readings generiert, wenn man sich den Datenbankinhalt mit "fetchrows" ausliest und anschaut. Der Readingname ist die eingeutige Kennzeichnung des Datensatzes bestehend aus Timestamp, dem Device, dem Reading (in der Datenbank) und Indizes zur Kennzeichnung von doppelten Datensätzen.
Das alles dient lediglich der Anzeige, aber auch dazu müssen Readings generiert werden.
Müssen diese Readings nun wegen dieser angekündigten Massnahme gekürzt werden, wird der Bezeichner nicht mehr eindeutig sein der Informationsgehalt fragwürdig. So mancher liest sich DB-Inhalte aus und speichert sie unter anderem Namen in Dummies etc.

Aber im Prinzip geht es mir darum, nicht alles zu regulieren nur weil man dem User (Author) die Mündigkeit abspricht selbst zu entscheiden womit er leben kann oder möchte.
Jeder Nutzer kann doch dem Maintainer mitteilen, dass er die Gestaltung der Readings zu lang oder wiedersinnig findet.
Ich vertraue diesbezüglich der Schwarmintelligenz.

Aber wie es scheint stehe ich damit auf verlorenem Posten.
Ich bitte also noch einmal darum dass sich die Entscheidungträger in Weitsicht üben und den Spielraum vergrößern.

Danke !

Was heißt feature Level 6?

Was wir auf jeden Fall verhindern sollten ist, dass Anwender, die einfach ein Update machen, nicht mehr arbeiten können. Und das schließt auch das neue Anlegen von Dingen ein. Vielleicht wäre ein Testlauf gut, wenn möglich in einem Entwicklungsbereich. Wenn Ihr es scharf schaltet, bevor die relevanten Module darauf ausgelegt sind, dann ist das Selbstmord für die Software.

Und noch einmal zu langen Namen:

Ich wäre dafür, so etwas wie die Aliasse auch für readings anzudenken und ggf. eine automatische Kürzung der Namen für die Anzeige, z.B. mit ..., ggf. mit Tooltips, die den langen Namen enthalten.

Und dann bin ich dafür, entweder einen langen Wert für die Grenze zu nehmen (200), oder einen sinnvoll kurzen, und das ist 20-30, denn 64 ist ein Wert, der weder für generische Namen, noch für Menschen gut ist. AUßerdem sollte das Limit dann auch für Gerätenamen gelten.

Horst

ZitatWas heißt feature Level 6?

Das bezieht sich auf das globale Attribut "featureLevel", welches bestimmte Funktionen im FHEM ein/ausschaltet.
Im Prinzip, um mal beim Beispiel DbRep zu bleiben, könnte ich die Verfügbarkeit der Funktion "fetchrows" davon abhängig machen ob der User das Attribut <6 eingestellt hat oder nicht. Dadurch könnte ich entscheiden ob eine sinnvolle Nutzung der Funktion mit Level > 6 möglich ist (oder andersherum).

Grüße,
Heiko

Zitat von: Harst am 19 Februar 2019, 18:15:32
Was heißt feature Level 6?

Wer solche Fragen stellt, sollte seinen Status als Developer überdenken.

Wg. der Umfrage: bisher gab es gar keine erzwungene Laengenbegrenzung, und das fehlt in der Liste.

Bei der Anfangsfrage von Betateilchen war meine erste Reaktion: wieso begrenzen? Und ich wollte sie ablehnen, aber da ich erst einen halben Tag spaeter dazukam, gab es schon etliche Beitraege, die alle fuer eine Begrenzung waren, also dachte ich: wenn die Mehrheit dafuer ist, von mir aus.

Persönlich finde ich es Sinnvoll wenn ein Modulauthor gezwungen wird über die Namensgebung von Readings sich Gedanken zu machen. Wir hatten hier schon diverse gruselige Vorfälle mit Readingsnamen.

@betateilchen: danke für die Blumen, wenn Ihr wollt, macht den Status wieder weg.

Aber ich habe jetzt gelernt, zu fragen, was ich nicht verstehe. Und jetzt weiß ich, dass featurelevel vom System vorgeben wird und nicht anderesherum vom User/Programm gesetzt wird.
Und dass es im Forum als Synonym zu einer Version verwendet wird.

Horst

Zitat von: Harst am 19 Februar 2019, 20:29:38
@betateilchen: danke für die Blumen, wenn Ihr wollt, macht den Status wieder weg.

Mein Hinweis war weder böse noch persönlich gemeint, sondern wirklich ein gutgemeinter Rat. Dinge wie featurelevel sollte man als Entwickler einfach kennen, wenn man in FHEM arbeitet. Und solche Grundlagen sind ja auch hinreichend dokumentiert.

Nix für ungut.

Zitat von: rudolfkoenig am 19 Februar 2019, 19:29:09
Bei der Anfangsfrage von Betateilchen war meine erste Reaktion: wieso begrenzen?

Zitat von: rudolfkoenig am 19 Februar 2019, 19:29:09
Wg. der Umfrage: bisher gab es gar keine erzwungene Laengenbegrenzung,

Diese Aussage ist definitiv falsch. Eine Längenbegrenzung für readings gibt es doch schon ewige Zeiten und sehr viel länger als die configDB gibt. In DbLog ist die Länge von readings derzeit mit 64 Zeichen festgelegt. Der Punkt ist einfach, dass diese Längen bisher nie in Anspruch genommen wurden. Das hat sich nun geändert.

Meine ursprüngliche Bitte nach einer Begrenzung bezog sich übrigens auf Attribute. Die Idee, readings und attribute letztendlich gleich zu behandeln, kommt nicht von mir. Aber dafür eine zentrale Funktion zu benutzen, die beides auf gültige Zeichen und Parameter prüft, macht auf jeden Fall Sinn.

Trotzdem muss die Diskussion erlaubt sein, ob überlange readings und attribute wirklich einen Sinn und/oder Nutzen haben. In diesem Sinne ist eine Begrenzung durchaus hilfreich.

Zitat von: CoolTux am 19 Februar 2019, 19:33:40
Persönlich finde ich es Sinnvoll wenn ein Modulauthor gezwungen wird über die Namensgebung von Readings sich Gedanken zu machen. Wir hatten hier schon diverse gruselige Vorfälle mit Readingsnamen.

*unterschreib*

Nur der Vollständigkeit halber:

ZitatIn DbLog ist die Länge von readings derzeit mit 64 Zeichen festgelegt. Der Punkt ist einfach, dass diese Längen bisher nie in Anspruch genommen wurden. Das hat sich nun geändert.

Der User hat die Freiheit die Feldlängen der DB bei Bedarf anzupassen und im DbLog-Modul per Attribut festzulegen dass diese individuellen Längen dann auch verarbeitet und nicht begrenzt werden.