Der OParl Update-Mechanismus: schnelles Aktualisieren eines lokalen Bestandes

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

[the-infinity]

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 second

Partielle 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 second

Wie man sieht, belaste ich mit der vollen Synchronisation den RIS-Server doch erheblich mehr und erheblich länger.

[akuckartz]

Offenbar gibt es keine Einigkeit, ob es Widersprüche zwischen dem Spezifikations-Dokument und dem Blog-Beitrag gibt bzw. was genau sich "indirekt" aus dem Spezifikations-Dokument ergibt.

Leider wurden meine Fragen unter dem Blog-Beitrag nicht so beantwortet, dass mir das jetzt klarer wäre. Ich sehe jedenfalls weiterhin nicht, dass sich die Ausführungen in dem Blog-Abschnitt "Modified-Handling bei eingebetteten Objekten" aus dem Spezifikations-Dokument "indirekt" ergeben würden oder auch nur damit kompatibel wären. Einen Beweis, dass sich ein Zwang zur "inversen" Vererbung von modified-Werten (eine prägnante Charakterisierung in #375 (comment)) aus dem Spezifikations-Dokument ergebe habe ich jedenfalls bisher nicht gesehen - oder ich übersehe etwas.

Ich würde jedenfalls gerne wissen, was ich beim Abruf von OParl-Daten genau erwarten kann (auch um dann Daten-Replikation mittels Linked Data-Techniken nutzen und anbieten zu können). Bedarf an redundanten "modified"-Werten habe ich nicht.

[the-infinity]

Indirekt ergibt sich das, was wir als Gedanken dahinter hatten, und diesen Gedanken habe ich im Blogbeitrag geschrieben. Das steht so nicht in der Spezifikation, weil die explizite Erwähnung eben durch eine Neuformulierung während der Überarbeitungsphase vor dem 1.0er-Release herausgefallen ist: 9868d58 und so nur noch einige wage Hinweise darauf übrig geblieben sind. Das ist schade, weil dadurch partielle Updates nicht mehr gehen, aber wir haben die 1.0 so released, also müssen wir damit leben, dass dem so ist.

Man könnte natürlich dieses Feature trotzdem anbieten, was der OParl Mirror auch tun wird, und wir können es Dritten empfehlen. Denn es macht inhaltlich halt einfach Sinn, siehe Beispiel. Nur man erreicht eben auch ohne eine OParl 1.0-Kompatibilität.

[sterni24]

Wir halten einen Update-Mechanismus für sehr wünschenswert, zumal viele unserer Kunden über Datenstände von 10, 15 oder gar 20 Jahren verfügen.

Wir haben den Ansatz von @the-infinity bei uns diskutiert und sind der Meinung, dass es eine Reihe von ungeklärten Fragen, insbesondere mit den entfernten Objekten, gibt. Hier nur ein Beispiel:

• ein Consultation-Objekt, das einfach nicht mehr existiert, fehlt in den Objektlisten
• vor dem Eintreten dieses Zustandes müssten ggf. mehrere Elternobjekte (-> Paper / -> AgendaItem,-> Meeting) modifiziert werden,
• betroffen ist in aller Regel noch ein File-Objekt.
• der Abgleich über ein Paper- / Meeting-Objekt müsste in jedem Fall eine Vollständigkeitsprüfung aller internen Objekte und verknüpften Objekte vornehmen, da nicht bekannt ist, ob und an welcher Stelle interne Objekte entfernt wurden.
• die Qualität der Daten ist kaum noch überprüfbar

Wie oben schon angedeutet, favorisieren wir einen Update-Mechanismus mit allen Objektarten. Dies ist u. E. auch die schnellste Methode. Man erhält nur das, was sich ändert. Jeder OParl-Client kann dann für sich entscheiden, ob er irgendwelche created-, modified- oder deleted-Werte in das jeweilige Elternobjekt transferiert.

Dazu sollte im Body-Objekt noch eine Eigenschaft eingeführt werden: updateMechanism (None / OParl / Sternberg / Both). Das wäre doch ein guter Ansatz für OParl 1.1 oder?

[akuckartz]

Es stehen mehrere sich widersprechende Tatsachenbehauptungen im Raum.

Die Überschrift des Blog-Beitrags lautet auch jetzt noch:

Der OParl Update-Mechanismus: schnelles Aktualisieren eines lokalen Bestandes

und der Text beginnt mit diesem Absatz:

Der Fokus von OParl 1.0 liegt auf einem schnellen und effizienten Abruf von Daten. Dies beinhaltet auch das schnelle und effiziente Aktualisieren eines lokalen Bestandes. Bei einer täglichen Synchronisation kann so mit einer geringen Anzahl an Anfragen an den OParl-Server ein Update durchgeführt werden. Diese Funktionsweise und die Nutzung dieses Mechanismus soll in diesem Artikel genauer beleuchtet werden.

Das wird jeden unbedarften Leser zu der Schlussfolgerung führen, dass in dem dann folgenden Text ein Haupt-Bestandteil der Spezifikation OParl 1.0 erläutert wird.

Fast am Ende des Textes steht nun:

UPDATE: weil dies in Github zum Thema wurde: dieser Mechanismus für Eingebettete Objekte ist nicht nötig, OParl 1.0 valide zu sein. Er ist von uns so geplant gewesen, ist dann aber durch eine Neuformulierung versehentlich herausgefallen, so dass es im Standard nur noch diverse Hinweise gibt, nicht aber eine klare Beschreibung. Kurzum: es wäre schön, wenn das Feature trotzdem implementiert werden könnte, aber es ist nun mal nicht OParl 1.0-Voraussetzung.

Das suggeriert in Verbindung mit der Überschrift und dem ersten Absatz des Textes, dass der Blog-Text eine Art optionaler Anforderung erläutert, die also nicht zwingend implementiert werden muss, um konform zu der Spezifikation Oparl 1.0 zu sein, die aber dennoch die Zustimmung der zum Zeitpunkt der Herausgabe aktiven Autoren der Spezifikation OParl 1.0 hat. Letzteres ist nicht der Fall, wie man am Eröffner dieses Issue sehen kann.

Hier in diesem Issue wurde in #375 (comment) auf 9868d58 verwiesen, um zu belegen, dass

die explizite Erwähnung eben durch eine Neuformulierung während der Überarbeitungsphase vor dem 1.0er-Release herausgefallen

sei. Ich habe mir diese Änderungen angesehen und habe in der ersetzten bzw. gelöschten kurzen Texten keine Spezifikation des "Update-Mechanismus" gefunden. Insbesondere sind darunter die Regeln im Abschnitt "Modified-Handling bei eingebetteten Objekten" des Blog-Beitrags nicht zu finden.

Tatsächlich stehen die in dem Blog-Beitrag enthaltenen Anforderungen offenbar in Widerspruch zu der Spezifikation OParl 1.0 und führen bei einer Implementierung zu einer Verschlechterung der Qualität der Daten der "modified"-Werte der Eltern. Diese Verschlechterung mag bei einigen Anwendungszwecken unproblematisch sein, ich bin jedoch an einer möglichst hohen Qualität interessiert und bitte deshalb die RIS-Hersteller, von der in dem Blog-Text vorgeschlagenen konkreten Implementierung Abstand zu nehmen, soweit die Datenqualität betroffen ist.

[the-infinity]

Nachdem wir uns das am Wochenende einmal genauer angeschaut haben, werden wir Sternbergs Vorschlag für OParl-Version 1.1 in den Standard übernehmen.
Die Idee ist ja auch nicht ganz neu, nur in einem früheren Zeitpunkt der OParl-Entwicklung gab es dagegen diverse Einwände, die v.a. auf "wir haben die Daten nicht, um das abzubilden" hinausliefen. Diese sind wohl schlicht nicht mehr aktuell, so dass sämtliche Objekte als Objektlisten von Body aus nunmehr problemlos möglich sind. Also: gleich die saubere Lösung.
Bonus: mein Fehler, dass ich aus Versehen den komplizierteren Ansatz herausüberarbeitet hatte, erweist sich nun als Vorteil, da wir nun ohne Breaking Change den besseren Ansatz einbauen können.

[the-infinity]

For the Records: der folgende Text stand früher im Blog und ist durch diese Diskussion nun obsolet.

---

Modified-Handling bei eingebetteten Objekten

Der oben beschriebene Update-Mechanismus kann nur dann funktionieren, wenn man einen genaueren Blick auf die eingebetteten Objekte wirft und dort sauber die Modified-Werte auch bei den "Eltern" aktualisiert. Um dies zu verdeutlichen, schauen wir uns das Paper von oben noch einmal genauer an:

    id: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/paper/13",
    type: "https://schema.oparl.org/1.0/Paper",
    body: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/body/1",
    name: "Unterschutzstellung des Bildstockes Ecke Triftstraße/Antoniusstraße in der Ortschaft Ginnick",
    reference: "V-4/2007",
    date: "2007-06-14",
    paperType: "Vorlage",
    mainFile: {
        id: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/file/1-127",
        type: "https://schema.oparl.org/1.0/File",
        body: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/body/1",
        name: "Vorlage (Unterschutzstellung des Bildstockes Ecke Triftstraße/Antoniusstraße in der Ortschaft Ginnick)",
        mimeType: "application/pdf",
        accessUrl: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/body/1/files/rim4992/UGhVM0hpd2NXNFdFcExjZZLUWrBty0zU28z_p4UFrKwU9pu0Gz_iPO0hlnPSFDZ8/Vorlage_V-4-2007.pdf",
        downloadUrl: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/body/1/files/rim4992/download/UGhVM0hpd2NXNFdFcExjZZLUWrBty0zU28z_p4UFrKwU9pu0Gz_iPO0hlnPSFDZ8/Vorlage_V-4-2007.pdf",
        created: "2010-01-20T17:32:45+01:00",
        modified: "2010-01-20T17:32:45+01:00"
    },

    consultation: [
        {
            id: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/consultation/8",
            type: "https://schema.oparl.org/1.0/Consultation",
            agendaItem: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/body/1/agendaitem/373",
            meeting: "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/body/1/meeting/257",
            organization: [
                "https://sdnetrim.kdvz-frechen.de/rim4992/webservice/oparl/v1/body/1/organization/184"
            ]
        },
        [...]
    ]
    created: "2010-01-20T17:32:45+01:00",
    modified: "2010-01-20T17:32:45+01:00"
}

Das im Paper enthaltene File sowie die enthaltene Consultation sind zunächst eigene Objekte, die aber gemäß der Regeln für die interne Ausgabe von Objekten (Kapitel 2.5.4) direkt im Paper-Objekt ausgegeben werden - damit spart man ebenfalls viele, viele Anfragen an den Server, weil man alle mit dem Paper zusammenhängenden Daten in einer Abfrage bekommt.

Jedoch bringt dies auch einen Fallstrick mit: wenn es eine Änderung im File-Objekt gibt, so muss diese ja auch bei einem Abruf mit gesetztem modified-Filter angezeigt werden. Dies ist auch logisch, denn es hat sich ja etwas im direkten Zusammenhang mit dem Paper verändert. Es ist daher also zwingend erforderlich, dass der modified-Wert des Paper aktualisiert wird, wenn das darin enthaltene File, die darin enthaltene Consultation oder andere interne Objekte eine Änderung erfahren.

In folgenden Fällen muss es also eine modified-Aktualisierung geben:

• Organization muss aktualisiert werden, wenn die enthaltene Location (Attribut: location) aktualisiert ein Update erfährt.
• Person muss aktualisiert werden, wenn die enthaltene Location (Attribut: location oder eine der enthaltenen Memberships (Attribut: membership) ein Update erfährt.
• Meeting muss aktualisiert werden, wenn die enthaltene Location (Attribut: location), einer der enthaltenen Files (Attribute: invitation, resultsProtocol, verbatimProtocol, auxiliaryFile) oder einer der enthaltenen agendaItems (Attribut: agendaItem) ein Update erfährt. Bei agendaItem ist zu beachten, dass diese wiederum ein Update erfährt, wenn einer der dort enthaltenen Files (Attribute: resolutionFile, auxiliaryFile) ein Update erfährt (eine Agendaitem->resolutionFile-Aktualisierung führt somit zu einer modified-Aktualisierung des Meetings).
• Paper muss aktualisiert werden, wenn die enthaltene Location (Attribut: Location), einer der enthaltenen Files (Attribute: mainFile, auxiliaryFile) oder einer der enthaltenen Consultations (Attribut: consultation) ein Update erfährt.

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.

Dieser modified-Mechanismus steht implizit mehrfach in der Spezifikation. Die explizite Erwähnung ist unglücklicherweise durch eine textliche Klarstellung herausgefallen, weswegen wir mit diesem Blogpost das Thema noch einmal gesondert darstellen wollten.

UPDATE: weil dies in Github zum Thema wurde: dieser Mechanismus für Eingebettete Objekte ist nicht nötig, OParl 1.0 valide zu sein. Er ist von uns so geplant gewesen, ist dann aber durch eine Neuformulierung versehentlich herausgefallen, so dass es im Standard nur noch diverse Hinweise gibt, nicht aber eine klare Beschreibung. Kurzum: es wäre schön, wenn das Feature trotzdem implementiert werden könnte, aber es ist nun mal nicht OParl 1.0-Voraussetzung.

[the-infinity]

Wird wie hier vorgeschlagen und diskutiert mit #380 umgesetzt.