Maximale Länge von Attributnamen begrenzen

[betateilchen]

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.

[herrmannj]

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

[CoolTux]

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

[Thorsten Pferdekaemper]

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

[KernSani]

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

[justme1968]

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

[betateilchen]

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.

[justme1968]

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.

[betateilchen]

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

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

[rudolfkoenig]

Gibt es das gleiche Problem auch mit dem Readings?

[betateilchen]

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.

[rudolfkoenig]

Die 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?

[herrmannj]

Mach doch mit Ansage und etwas Vorlauf

[betateilchen]

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.

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.

[CoolTux]

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.