Description
Mit dem OParl-Blog 05.09.2017 wird ein Update-Mechanismus festgelegt, den wir in dieser Form nicht akzeptieren. Es kann nicht sein, dass die OParl-Verantwortlichen hier ohne Absprache mit den RIS-Herstellern eine Verfahrensweise festlegen, die nicht in der Spezifikation enthalten war. Das beschriebene Szenario geht voll zu Lasten der RIS-Entwickler:
Zitat aus Blog: Hintergrund dieses Mechanismus ist, dass in den bestehenden Ratsinformationssystemen oft keine Informationen für die eingebetteten Objekte verfügbar sind. Damit gibt dort oftmals gar keine created- oder modified-Werte, so dass man daraus keine externen Objektlisten von Body generieren könnte. Da wir als OParl-Entwickler eine praxisnahe, aber trotzdem funktionsfähige und schnelle Lösung haben wollten, haben wir uns damit dann für die interne Objektausgabe inkl. der oben beschriebenen Regeln für die modified-Werte entscheiden.
Wir halten einen Abgleich aller Objekte für wesentlich effizienter, als die "inverse" Vererbung von modified-Werte der internen Objektlisten. Letzteres bedeutet einen erheblichen Änderungsaufwand für die Entwicklung, zieht umfangreiche Testläufe nach sich und führt zu wesentlich längeren Ausführungszeiten beim Abruf der Daten.
In unserem System sind für alle Objekte entsprechende created, modified und deleted-Werte vorhanden. Sollte dies bei anderen RIS-Systemen nicht der Fall sein, können hier beim Erzeugen der Objektlisten von internen Objektarten die entsprechenden Werte der Elternobjekte eingesetzt werden. Deleted-Werte müssen für jede Objektart separat bereitgestellt werden.