[PostNAS] alte Einträge in der alkis_beziehungen vorhanden

[Jäger, Frank (KRZ)]

Hallo,
wie eine Beziehung in die Datenbank kommt, habe ich noch nie analysiert. Aus dem Code des Konverters selbst habe ich mich bisher rausgehalten.

Aber zu Delete/Replace kann ich was sagen:

Alle aus NAS-Delete- und NAS-Replace-Anweisungen resultierenden SQL-Delete für die ALKIS-Objekte und ihre Beziehungen laufen über die Tabelle "delete" und ihre Trigger. Ich beschreibe die Variante -kill (siehe vorangegangene Mail).


NAS: DELETE

Ein NAS-Delete-Satz für ax_flurstueck wird von PostNAS per SQL in die Tabelle "delete" eingetragen.
Der Trigger löst dann die "FUNCTION delete_feature_kill()" aus und diese löscht sowohl die alte Version des Objektes als auch alle "alkis_beziehungen" von und zu der betroffenen gml_id.
Der Eintrag in der delete-Tabelle ist danach überflüssig, es sei denn man möchte dort nachsehen, ob eine bestimmte gml_id mal gelöscht worden ist. 
Man kann die delete-Tabelle also nach der Konvertierung leeren. Allein der SQL-Insert in die delete-Tabelle ist wichtig, weil dies den Trigger auslöst. 

Im Script "konv_batch.sh" wird am Ende die Anzahl der Zeilen ausgegeben.
  echo 'SELECT COUNT(featureid) AS delete_zeilen FROM "delete";'
Vor Beginn des nächsten Laufes wird die Tabelle geleert:
  TRUNCATE table "delete";
Zwischen zwei Läufen kann man nachsehen, was gelöscht worden ist.


NAS: REPLACE

Ein Replace-Satz für ax_flurstueck wird vom Konverter in ax_flurstück eingetragen *und* in die Tabelle "delete".

Der Trigger löst dann die gleiche "FUNCTION delete_feature_kill()" aus und die löscht die "alten Versionen" des Objektes.
Als Kriterium wird das "beginnt"-Datum verwendet. Das Objekt mit dem höchsten Datum in "beginnt" bleibt bestehen, alle mit gleicher gml_id aber älterem "beginnt" werden gelöscht.
Das habe ich mal als Hilfslösung so codiert, weil mir gerade nichts Besseres eingefallen ist. Wahrscheinlich wird das jetzt - wie alle Provisorien - jahrelang gute Dienste leisten.
Zuvor hatten wir ein paar Monate lang eine fehlerhafte Lösung. Es wurden in der Function alle Einträge mit der gml_id gelöscht in der irrigen Annahme, dass danach erst das neue Objekt eingefügt wird. Das neue Objekt ist aber schon da, wenn der Trigger durch Eintrag in "delete" ausgelöst wird. Es muss verschont werden. Diese Lösung geht davon aus, dass das Objekt mit dem spätesten beginn-Datum zur gml_id das einzig richtige ist.

Wenn die gml_id gleich geblieben ist (was offensichtlich immer der Fall ist) bleibt die Tabelle "alkis_beziehungen" beim Replace eines Objektes vom Trigger unberührt. Wenn sich die gml_id (replaced by ..) geändert hätte würde ein Fehler ausgeworfen, das habe ich noch nicht beobachtet.

In den Kommentaren im Trigger, nachzulesen in "alkis-functions.sql" ab Zeile 365, habe ich notiert, dass die Beziehungen dann doppelt eingetragen sind.
Die redundanten Zeilen werden derzeit nach der Konvertierung per SQL entfernt. Es wäre natürlich besser, wenn der Trigger sich bei jedem Objekt sofort darum kümmern würde. Dann wäre die Datenbank auch während der Konvertierung konsistent (Konverter und Benutzung parallel?).
Der Entwurf einer Lösung ist auch schon dort skizziert. Mir fehlte wohl die Zeit, dass auszutesten. Somit ist erst mal die Quick&Dirty-Lösung zum Einsatz gekommen.   

Wer interessante Herausforderungen sucht, kann ja mal probieren, ob das ein gangbarer Lösungsweg wäre.


Mfg
Frank Jäger


-----Ursprüngliche Nachricht-----
Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Brandt, Marvin
Gesendet: Dienstag, 19. Februar 2013 16:45
An: NAS Schnittstelle via ogr2ogr
Betreff: Re: [PostNAS] alte Einträge in der alkis_beziehungen vorhanden

...
An welcher Stelle werden die Beziehungen aktualisiert, wenn im replace Datensatz in der NAS-Datei eine neue ID für die Verknüpfte Buchungsstelle eingetragen ist.
...

Vielleicht wird mir der Ablauf dann etwas klarer.

Mit freundlichen Grüßen
Im Auftrag

Marvin Brandt