Ich habe gerade (beinahe) ein kleines Fiasko erlebt, weshalb ich diesen Vorschlag mache:
Wenn man ein Objekt im Objektbaum löschen will, muss man „rechte Maustaste“ - löschen drücken.
Soweit, so gut.
Ich schlage zwei Dinge vor:
1.) Die übliche Löschbestätigung (wollen Sie …), denn die Löschung - gerade mit Hinblick auf verwendete ID’s möglicherweise in zig Scripten ist schon u.U. recht weitreichend.
2.) Prüfung, ob Links auf das zu löschende Objekt weisen.
Und ne weitere Anregeung (muss ja nicht sofort vollständig umgesetzt werden):
3.) „Recovery“ auch für Objekte (Scripte werden ja glücklicherweise in „Deleted“ geschoben).
Man könnte z.B. gelöschte ID’s erstmal für einige Erstellungszyklen von Objekten „sperren“, um ein Recovery möglich zu machen (im XML einfach stehen lassen und nur Kennzeichnen ???)
Völlig korrekt! Da sollte unbedingt was derartiges passieren!
Da stößt mir natürlich sofort wieder der alte Widerspruch zwischen technischen und funktionalen Identifikatoren auf:
Natürlich müssen zur Abbildung von Bezügen systemweit eindeutige, notfalls automatisch generierte IDs existieren und genutzt werden, die niemals einen direkten Kundendatenbezug haben dürfen, damit bei „Kunde ändert mal eben den Bezeichner“ nicht alle Bezüge verloren gehen. Die jetzigen IDs sind da völlig richtig und entsprechen dem völlig. Rein numerisch sind sie sogar darüber hinaus auch noch optimal schnell.
Andererseits muß es aber, eben um eine Replikation auf andere Systeme, Wiederherstellbarkeit etc. als Möglichkeit offen zu halten, optional nutzbare Verfahren und Wege geben, diese IDs dediziert zu setzen (natürlich mit Test „noch frei?“, implizit oder explizit).
Datenbanken machen das zB, indem auch beim neu Anlegen eines Records (sozusagen das „Objekt“) die ID gesetzt werden MUSS! Existiert sie bereits im System, kommt es zu einer Fehlermeldung und Prozess schlägt fehl. Automatik wird dadurch erreicht, dass eine (auch abgesetzt nutzbare) Funktion wie „newID()“ in einer Autowert-Spalte eine neue ID generiert, so keine angegeben wurde.
Auf IPS übertragen würde das bedeuten, dass für den Defaultfall natürlich alles bleibt wie es ist, aber OPTIONAL eine ID übergeben werden kann beim ANLEGEN von Objekten. Diese KANN vorab durch eine Funktion wie „newID()“ generiert werden, aber bedarfsweise eben auch (und deshalb der ganze Aufwand) gezielt gesetzt werden.
Solange die Eindeutigkeit der IDs gesichert bleibt, geht dann alles:
Recover-Funktion: z.B. aus eine Backup-Liste der „mal verwendet gewesenen Objekte“, die NICHT beachtet wrd bei „newID()“, also deren IDs wiederverwendbar sind - recovern ist nix anderes als das!
Übertragen ganzer Projekte auf andere Systeme. Die o.g. „Schutzfunktion - Test auf Eindeutigkeit im System“ sichert auch die Übertragung von Projektteilen ab, der Anwender muß dann eben und logischerweise selbst dafür sorgen, dass schon vorhandene Objekte im Zielsystem nicht zu Doubletten führen
Funktionale Keys. (und darum ginge es mir selbst am meisten). Der Anwender kann sich seine eigenen, ggf. auch aus Kundendaten abgeleiteten oder dazu synchronisierbaren funktionalen Keys aufbauen und verwalten - ohne Widerspruch zu den teechnischen Keys darunter, replizierbar und recoverbar!
Ich weiß, das klingt kompliziert, ist im Grunde aber völlig simpel und beseitigt genau solche Probleme wie die im Initialbeitrag beschriebenen
Zu Punkt 1 und 2 auch mein klares „PRO“… Ist mir zwar noch nicht passiert aber erscheint mir sinnvoll und sollte auch nicht sooo kompliziert umzusetzen sein. Kenn aber den Code genausowenig wie Ihr.
Zu Punkt 3 muss ich sagen dass ich die Gefahr sehe, das IPS dann so langsam von ner kleinen, schlanken und performanten Steuersoftware zu nem dicken aufgeblähten Festplattenmonster wird. Irgendwann steht dann in den Systemvoraussetzungen Dual-Core mit min 2 Gig freier Festplatte. Und aus ists mit Atom-Basis. :rolleyes:
@gwanjek:
Wenn ich deine langen Beiträge sehe hab ich immer schon keine Lust mehr sie zu lesen. Aber im prinzip hast du Recht. Der Ansatz ist bestimmt nicht schlecht. Aber IPS hat lediglich 16 Bit Adressbereich. IDs zu recyclen ist somit ökonomisch durchaus sinnvoll. Und du möchtest nicht wirklich 10 stellige IDs (32 Bit), oder?
Du wirst immer das Problem haben, dass eine ID, die du in einem Script verwenden willst schon vergeben ist. Unabhängig davon gibt IPS_CreateVariable eine ID zurück und man kann sich darauf verlassen, dass sie vorher frei war und nun vergeben ist. Das kommt deinem Vorschlag schon sehr nahe, nur hat man vorher halt keinen Einfluss drauf. Aber was hast du denn davon, wenn du wüsstest, dass deine „Wunsch-ID“ schon vergeben ist?
Aber daher sage ich ja auch: „Vorhaltezeit“ für gelöschte ID’s (meist merkt man ja das Problem binnen Minuten/Stunden oder längstens einer Woche.
Oder man hält max. 20/30 ID’s geblockt …
Es geht ja um’s Löschen von Objekten, und im Normalfall wird sich das wohl eher im Bereich einzelner Objekte denn großer Anzahlen abspielen, oder?
Was die Größe der Settings angeht: Gelöschtes in 2. XML auslagern, für die „interne“ Arbeit in der Settings einen weiteren Eintrag „reseved ID’S“ machen, (fast) fertig.
Du meinst also eher so eine Art „Papierkorb“ für Objekte. Das würd ich so umsetzen, dass ein Objekt ein Löschdatum als Eigenschaft bekommt. Ist die ungleich 0 oder ungleich „unset“ (der Abwärtskompatibilität wegen), so gilt das Objekt als „im Papierkorb“. Ist es älter als X, dann kann es ggf. automatisch gelöscht werden. Das wäre dann aber eher ein Bonus, den man IMO auch abschalten können muss oder vielleicht auch gar nicht erst implementieren sollte.
Auf diese Weise sind die IDs dann auch automatisch „geblockt“, wie du es nennst, denn die Objekte existieren ja noch. Eine 2. Settings macht eher mehr arbeit.
Kann man sich drüber streiten ob das sinnvoll ist oder nicht. Ich hätte, glaub ich, keine Verwendung dafür.
Keine „wirkliche“ zweite Settings, die zur Laufzeit Relevanz hat, eher ein „wegkopieren“ aller Properties, um diese später sehr einfach wieder (ggf. sogar manuell) in die (einzige) Settings.xml zu bekommen.
Blockieren/Reservieren von IDs deshalb, damit beim Neuanlegen von Instanzen nicht „zufällig“ die ID eines (kürzlich) gelöschten und noch „warmen“ Objektes verwendet wird und damit die spätere Wiederherstellung des Gelöschten blockiert wird.
Na und zur Notwendigkeit: natürlich wird ein Profil wie Du im Worst Case kurzerhand in der Settings händisch aufräumen … das bedeutet aber ggf. doch ziemlich Arbeit …
dabei einen Fehlerabbruch haben, falls diese dann schon vergeben ist
Mitunter muß man Sachen eben zu ende lesen, um sie zu verstehen. …und wollen.
Wo bitte soll da ein Moloch sein? Wie ich schrieb (falls man das dann auch lesen mag): Numerische IDs sehe ich als sehr sinnvoll und schnell an!
Die Überprüfung gegen Doubletten muß ja jetzt auch schon intern da sein, denn auch zufällig gewählte Ziffern können schon vergebene als Treffer liefern. Dazu wäre lediglich ein Input für optional vorgegebene Nr. zu vergeben.
Die „Backupliste“ war lediglich ein machbarer(!) Vorschlag auf den Wunsch nach einer Recover-Version. Ohne die irgendwo zu speichern, müßte IPS schon esoterische Fähigkeiten besitzen, um das zu tun! Und eine geradeaus-Liste / Datenbank-Tabelle von Integer-Werten, ggf. zzgl. Zeitstempel als Moloch zu bezeichnen, naja. Kopfschüttel
Genau. Und da hab ich angesetzt und frage mich:
Wenn ein Projekt oder Teilprojekt verschoben, exportiert, oder gelöscht und wieder hergestellt werden soll, sollte man es dann nicht gleich so schreiben, dass dies auch möglich ist? Das beinhaltet dann auch IPS-Variablen als Schnittstelle dynamisch zu generieren. Und wenn sie eh dynamisch generiert werden, dann ist auch egal wie sie heissen.
In der Praxis heisst das, dass man für Scripte, die man weitergeben will, ein Installationsscript benötigt (kann ja in der selben Datei stehen), dass sinniger Weise eine Kategorie und Variablen anlegt. In dem eigentlichen Script muss dann mit getVariableByName (oder wie das gleich heisst :D) danach gefahndet werden. Klar ist das lästig aber IMO gibt es auch keinen Grund ständig Scripte und Variablen zu ex- und importieren. Ausser wenn man sie weiter geben will. Und dann sollte man den Aufand schon auf sich nehmen.
Mitunter muß man Sachen eben zu ende denken, um sie zu verstehen. …und wollen.
Zur Erinnerung (falls das Lesen des Eingangs-Problems zu schwer fällt) : User hat „aus versehen“ wichtiges Objekt gelöscht und will, ohne alle IDs an den Stellen der Verwendung ändern zu müssen, dieses wieder herstellen. Logischerweise ist Platten-/Bandsicherung etc. zwischenzeitlich auch nicht gelaufen.
Er will lediglich versehentlich gelöschtes Objekt wieder herstellen, MIT SEINER vorher vorhandenen ID, die logischerweise ja wohl wieder frei ist!
Nun soll er also -noch dazu mitten im Entwicklungsprozess- immer eine ID-redundante Wiederherstellungssequenz vorhalten??! Ich bitte Dich! Das solltest Du doch wohl selber als total unpraktikabel einschätzen können!
Zweitens: Am „produktiven“ System rumzuspielen, ist nicht immer Vorteilhaft. Im richtigen Leben macht man das auf einer „Dev“-Umgebung, bevor das dann auf „Prod“-System eingespielt wird.
Einspielen heißt dabei NICHT, Kopie des gesamten Systems mit allen Verzeichnissen! Logischerweise hätte Dein Vorschlag (dem ich bzgl. Weitergabe uneingeschränkt zustimme) zur Folge, dass JEDE Änderung des eigenen Systems ein derartiges ID-redundantes Install-Szenario in sich tragen müßte.
Wenn ich meine neuen(!) Objekte sowie das Zielsystem genau kenne, kann ich die ja sehr wohl dediziert setzen, ohne ID-Konflikte zu provozieren!
Sicherheitshalber Doubletten dann auch noch abzufangen, wäre lediglich eine Option zur Erhöhung der Stabilität bzgl. Fehler abfangen usw., damit das produktive System geschützt bleibt
Klar ist es, grade bei komplexeren System, sinnvoll in der Testphase nicht direkt Beleuchtung zu blockieren. Was spricht dagegen sich die IDs oben im Script blockweise in eine lokale Variablen zu schreiben und je nach dem ob das Script scharf läuft oder im Testbetrieb die Blöcke auszukommentieren? So mach ich es und komme super damit klar. In meinen Augen ist das absolut zumutbar.
Wenn du dir als „skilled-user“ die Mühe machst eine „dev-Umgebung“ aufzubauen, dann kannst du für deine hand voll Variablen auch die Mühe machen die IDs von Hand, ohne grafische Oberfläche, zu vergeben. Oder du arbeitets gleich auf nem Mirror, der dann automatisch schon die selben IDs verwendet. Warum muss jetzt die grafische Oberfläche oder das Scripting Interface mit „Zeug zugespammt“ werden, dass ein Neueinsteiger unnötig verwirrt oder gar abschreckt? Das Handling wird für deinen Spezialfall einen Klick einfacher aber für den Rest der Welt erschließt sich nicht wann man die IDs vergeben muss und wann man es tunlichst lassen sollte.
Zur Erinnerung (falls das Lesen des Eingangs-Problems zu schwer fällt)
Diese Seitenhiebe hab ich lange genug „übersehen“. Das ist absolut unangebracht und kindisch. Auf dem Niveau mach ich an dieser Stelle nicht weiter.
Könnte ja - rein theoretisch - auch sein, dass das allzu ausschweifende umschreiben einer Gegebenheit deutlich weniger attraktiv zu lesen ist als einfach ein Problem auf den Punkt zu bringen.
1+2 finde ich gut. Zusätzlich werde ich mal sehen, ob ich nach den IDs in Skripten suchen werde…
Nein.
-> Zu IDs manuell setzen… Beim Erstellen geht es einfach nicht, da z.B. die Variablen automatisch erstellt werden. z.B. bei einem UVR1611 sind es 60 Stück. Wenn du da die IDs manuell einstellen willst, wirst du nicht fertig. Evtl. könnte man für Pro’s erlauben eine ID hinterher zu ändern. Aber das wäre kompliziert ins System einzubinden… Und ein Pro kann in diesem Ausnahmefall ja schnell die settings.xml editieren.
Aber im prinzip hast du Recht. Der Ansatz ist bestimmt nicht schlecht. Aber IPS hat lediglich 16 Bit Adressbereich. IDs zu recyclen ist somit ökonomisch durchaus sinnvoll. Und du möchtest nicht wirklich 10 stellige IDs (32 Bit), oder?