the-infinity
commented
7 years ago Zunächst einmal: der Mechanismus stand so explizit nicht in der 1.0er Spezifikation drin, also ist auch ein OParl ohne dieses Feature valide. Der Mechanismus ist wie im Artikel beschrieben irgendwann aus Versehen herausgefallen, so dass an verschiedenen Stellen noch Hinweise darauf zu finden sind, die implizit diesen Update-Mechanismus zur Folge haben - aber eben nur indirekt, und da es nicht direkt da steht, müssen wir mit dem Stand so leben. Deswegen steht der Artikel auch auf dem Blog und wurde nicht in ein Update der Spezifikation verwandelt. Sorry, falls das falsch verstanden wurde, ich habe dazu auch noch einen Absatz im Artikel ergänzt.
Die Frage ist allerdings trotzdem, wie man einen schnelleren Abruf machen kann. Die Synchronisation aller Objekte dauert insbesondere bei größeren RIS doch ein bisschen länger, so dass es zumindest wünschenswert wäre, wenn man immer nur den veränderten Bestand bekäme[*]. Man könnte natürlich wie angesprochen von Body aus Objektlisten von jedem einzelnen Objekt machen. Dies hatten wir damals verworfen, weil uns folgende zwei Gegenargumente genannt wurden:
- Die nicht vom Body aus verlinkten Objekte haben nicht in allen RIS die Attribute created oder updated
- Wenn man Objekte wie AgendaItem zu Objektlisten macht, würden dort sehr viele deleted Einträge drinstehen, weil sich sowas wie eine Tagesordnung regelmäßig ändert (wenn ich mich richtig erinnere, hat gerade dieser Punkt bei dem Workshop zu Diskussionen geführt, so dass wir uns dann letztlich für den beschriebenen Update-Mechanismus entschieden hatten)
Wenn diese beiden Punkte doch nicht so viel Aufwand bedeuten, so bin ich einer Lösung mit Objektlisten aller Objekte sehr aufgeschlossen gegenüber.
[*] Praxisbeispiel bei einer sehr kleinen Gemeinde (Aldenhoven). Volle Synchronisation:
2017-10-12 08:05:48,986 INFO: mongodb requests: 21553
2017-10-12 08:05:49,026 INFO: http requests: 73
2017-10-12 08:05:49,027 INFO: mongodb time: 275.2 s
2017-10-12 08:05:49,029 INFO: minio time: 0 s
2017-10-12 08:05:49,030 INFO: http time: 150.0 s
2017-10-12 08:05:49,031 INFO: file download time: 0 s
2017-10-12 08:05:49,032 INFO: wait time: 14.4 s
2017-10-12 08:05:49,033 INFO: app time: 91.0 s
2017-10-12 08:05:49,034 INFO: all time: 530.6 s
2017-10-12 08:05:49,035 INFO: processed 40.6 objects per secondPartielle Synchronisation
2017-10-12 08:07:05,631 INFO: mongodb requests: 5
2017-10-12 08:07:05,632 INFO: http requests: 5
2017-10-12 08:07:05,633 INFO: mongodb time: 0.0 s
2017-10-12 08:07:05,634 INFO: minio time: 0 s
2017-10-12 08:07:05,635 INFO: http time: 0.8 s
2017-10-12 08:07:05,636 INFO: file download time: 0 s
2017-10-12 08:07:05,637 INFO: wait time: 0.8 s
2017-10-12 08:07:05,638 INFO: app time: 0.0 s
2017-10-12 08:07:05,639 INFO: all time: 1.7 s
2017-10-12 08:07:05,640 INFO: processed 2.9 objects per secondWie man sieht, belaste ich mit der vollen Synchronisation den RIS-Server doch erheblich mehr und erheblich länger.
akuckartz
sterni24
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.