Wir sind aktuell am überlegen, ob man die ID der Hauptkategorie von 0 auf 1 ändert. Das hat ein paar Vorzüge, aber auch kleine Herausforderungen die wir im aktuellen Stream ausführen: https://www.youtube.com/live/ASh-bt55VAw?feature=share&t=2871
Da die Änderung doch recht groß ist, würden wir da gerne auch euer Feedback zu haben. Haben wir vielleicht relevante Anwendungsfälle oder Herausforderungen übersehen? Falls ihr etwas habt, wo ihr mit der ID der Hauptkategorie arbeitet, meldet euch gerne mal, ob die Anpassung dort Probleme bereiten könnte oder spätestens mit kleinen Anpassungen problemlos machbar ist.
Ihr habt vor kurzem erst angefangen einige andere Anwendungsfälle auf 1 zu setzen. Auch wenn PHP immer typsicherer wird, würde ich vorschlagen einen Wert zu nehmen, der NICHT autom. boolean werden könnte bzw. auch andersherum einen bool falsch zurückwandelt. z.B. 9
Aber mal generell gefragt, wenn IDs 5 stellig sind - warum dann die 0 oder 1? Warum nicht fix die 10000? Kenne ja den Mechanismus nicht dahinter um richtig Mitzudiskutieren. Vielleicht könnt Ihr mehr Rahmenbedingungen aufzählen die zu der damaligen Entscheidung 0 geführt haben und jetzt die Umbenenung erschweren.
… weil 10000 bis dato eine gültige ID ist und daher in manchen Installationen schon vergeben sein könnte - wurde gestern im Webinar angesprochen.
Letztendlich für „0“, „1“ , „-1“ kann man sich ja immer irgendwelche Szenarien zusammenreimenwo durch kreative Programierung etwas schieflaufen könnte.
Von da her wäre wohl doch 9999 die sicherste Variante, auch wenn es keine „schöne“ Zahl ist.-
Gegenfrage - ist das Root keine gültige Kategorie?
Daran hatte ich auch gleich gedacht, wollte damit noch nicht rausrücken ohne die Hintergründe genau verstanden zu haben. Und 100000 war auch noch so eine Idee
Es ist eine gültige Kategorie - aber in einer von allen Kundensystem könnte die 10000 bereits genutzt werden und dann wäre die nicht mehr frei. Deswegen geht dies leider nicht.
Ich verstehe gerade noch nicht, warum euch die 1 missfällt. Wobei die eigentliche Zahl tatsächlich egal ist - vorrangig wäre die Frage, wo aktuell die 0 als Root-Kategorie genutzt wird und nun Abwärtskompatibilitätsprobleme erzeugen könnte
die Frage ist, wie aufwendig wäre das von euch umzusetzen? Man könnte eine spezielle Version bauen und an auserwählten verteilen um zu sehen ob und wo es knallt. Denn wenn Ihr es nicht erahnen könnt, woher dann wir
Wir fühlen uns aktuell recht wohl und ich denke es wäre definitiv einen Versuch Wert. Problem ist eher, dass die settings.json dabei teilweise konvertiert wird und man nur mit einem Backup zurück kommen würde, wenn wir ein Problem bemerken.
Die Frage zieht eher darauf ab, ob irgendwem doch zufällig etwas auffällt, was wir übersehen haben könnten, da die Änderung doch an einer eher speziellen Stelle stattfindet
An etlichen Stellen (z.B. die Konfiguratoren) werden neue Instanzen ohne explizite Kategorie-Angabe angelegt. Dadurch landen Sie in der root. Dies passiert vmtl. auch durch eine Vorbelegung des internen Parameters ‚Parent-ID‘ mit 0. Wie würdet ihr dies später lösen? Wäre das intern dann einfach auf 1 vorbelegt?
An einem (mir gerade nicht präsenten) Konfigurationsformular-Feld habt ihr vor kurzem erst den Default auf 1 gesetzt, um der Root-Kategorie aus dem Weg zu gehen. In wie Weit müsste man hier nochmal anpacken?
Ich habe nix gegen die 1, mit mehr Wissen kann man aber ein bessere Entscheidung treffen Und wenn man jetzt einmal was ändert dann vielleicht gleich die beste Lösung
ich finde die Idee, das die Root-Kategorie nicht mehr 0 ist, sehr gut; da die 10000 ja nicht sicher ungenutzt ist, scheint mir 1 auch logisch.
Die Stellen, wo ich darauf setze, das die Root-Kategorie den Wert 0 hat, sind auf den ersten Blick überschaubar; da geht es nur darum, das diese Kategorie keinen Parent hat und daher kein IPS_GetParent() aufgerufen wird.
Ich bin skeptisch bei solchen Änderungen. Im Zweifel ist das immer ein Breaking Change, niemand weiß genau wann und wo es knallt, denn die Anwenderskripte sind im Zweifel eher mal schnell hingeschrieben. Jedes veränderte Verhalten von IPS ist ein Risiko, dass plötzlich im ganzen Gebäude irgendetwas nicht mehr funktioniert. Klar, die „Schuld“ ist beim Skript das vielleicht irgendwelche unsauberen Checks durchführt, die Schuld ist beim Anwender, der Frust aber auch.
Ich kann gut verstehen wenn irgendwann mal alte Zöpfe ab müssen, alte Inkonsistenzen aufgelöst o.ä. aber ich finde es bedenklich, einfach so ohne wirkliche Not am Verhalten einer Gebäudesteuerungs-Software herum zu ändern. Ich persönlich würde mir wünschen, dass solche Änderungen die absolute Ausnahme bleiben. Nicht umsonst gibt es Leute, die noch mit völlig veralteten Versionen herumwursteln, weil sie sich vor den bekannten und unabsehbaren Folgen von Breaking Updates fürchten.
Es gibt ja nicht nur eine Hauptkategorie, sondern mehrere (I/O, Splitter, Kern etc).
Sollten dann nicht verschiedene ObjektIds genommen werden? Mein Vorschlag wäre, jeder Hauptkategorie eine eigene ID zu geben und dafür auch Konstanten zur Verfügung zu stellen.
Das ist leider nicht korrekt. Es gibt nur die eine Hauptkategorie. Alles andere, was du in der Konsole siehst, sind optische Kategorisierungen nach einem speziellen Filter (wie Instanztyp) und haben keinerlei spezielle ParentID. (Deshalb siehst du bei der ObjektID in der Konsole auch keine ID angezeigt)
Die Not ist da - und dieser Beitrag ist genau dazu da, um abzuwägen, wie viele Probleme diese Änderung haben könnte. Bisher ist dies aber überschaubar.
Ich sehe das Problem, dass eben dies durch Diskussionen nicht wirklich feststellbar ist. Am Ende zeigt es sich meistens, wenn’s nach dem Update im Livebetrieb irgendwo ein Problem gibt.
Aber wenn’s wirklich not tut; das kann ich natürlich nicht einschätzen.
