Maximale Länge von Attributnamen begrenzen

[DS_Starter]

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 !

[Harst]

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

[DS_Starter]

Was 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

[betateilchen]

Was heißt feature Level 6?

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

[rudolfkoenig]

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.

[CoolTux]

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.

[Harst]

@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

[betateilchen]

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

[betateilchen]

Bei der Anfangsfrage von Betateilchen war meine erste Reaktion: wieso begrenzen?

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.

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*

[DS_Starter]

Nur der Vollständigkeit halber:

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.

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.