Maximale Länge von Attributnamen begrenzen

[Harst]

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

[rudolfkoenig]

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.

[DS_Starter]

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:

Code Auswählen Erweitern


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

[DS_Starter]

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.

[rudolfkoenig]

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.

[DS_Starter]

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 ?

[rudolfkoenig]

Mit 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

[DS_Starter]

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 ....

[betateilchen]

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*

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.

[betateilchen]

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.

[DS_Starter]

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 ...

[betateilchen]

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.

[DS_Starter]

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 ...

[KernSani]

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 )

[betateilchen]

(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.