[PostNAS] Antworten zu Delete/Replace

[Astrid Emde]

Hallo Frank,

das NBA Verfahren war ja so gedacht, dass wir in mehreren Schritten vorgehen

1.) erst der Layer Delete geladen wird (Laden der Lösch- und
Replacedatensätze)
2.) dann werden die zu löschenden Datensätze gelöscht über den Trigger
3.) dann wird der Fortführungsdatensatz nochmals geladen und die
Replacedatensätze dabei wieder angelegt

Siehe auch :
http://trac.wheregroup.com/PostNAS/wiki/SchrittfuerSchritt

Oder hatte ich hier etwas falsch verstanden?

Schönen Gruß

Astrid

Am 29.10.2012 10:30, schrieb "Jäger, Frank (KRZ)":
> Moin!
>
>> Hat sich eigentlich mal jemand die Trigger angeschaut?
> Meine Frage vom Mai darf ich mir jetzt selbst mit "Nein" beantworten.
>
> Wir haben seit Monaten Probleme nach Aktualisierungen der NBA-Sekundärbestände. Nach einer NBA-Erstabgabe sieht das Kartenbild zunächst vollständig aus. Nach Aktualisierung mit Differenzdaten sind dann die Flurstücke nicht mehr flächendeckend, Grundbücher haben in der Auskunft keine Eigentümer mehr usw.
> Ich habe nun heraus gefunden, dass es an dem Trigger im Datenbankschema [1] liegt, der die "replace"-Sätze verarbeitet.
>
> CREATE .. FUNCTION delete_feature_kill() ..
> ..
>         ELSE
>                 -- replace
>                 query := 'DELETE FROM ' || NEW.typename || ' WHERE gml_id = ''' || gml_id || '''';
>                 EXECUTE query;
>                 -- alkis_beziehungen bleibt so
>         END IF;
>
> Es wird vom Konverter zunächst das neue Objekt eingefügt, dann erst der replace-Satz in die delete-Tabelle, der den Trigger auslöst.
> Zu dem Zeitpunkt stehen also altes und neues Objekt in der Objekt-Tabelle und beide haben dummerweise die gleiche "gml_id".
>
> Da über die "gml_id" das SQL delete qualifiziert wird, erwischt es auch den neuen Satz. Somit hat der NAS "replace" die Wirkung vom NAS "delete".
>
> Ich hatte die ganze Zeit vermutet, das wäre ein lokales Problem, denn niemand anderes hat von ähnlichen Problemen berichtet. 
> Wenn das Schema auf dem Trunk benutzt wurde, müssen aber eigentlich alle das gleiche Problem haben. Warum hat niemand etwas gemerkt?
>
> Der Trick ist nun, in dem Trigger den Datensatz zum alten Objekt zu löschen aber den neuen Datensatz drin zu lassen.
> Ich denke, ich habe eine Lösung gefunden, aber nicht sehr elegant: Das maximale "beginnt" zu einer gml_id wird zuvor ermittelt und beim SQL delete verschont. Hätte man diese Info in der delete-Tabelle wäre es schneller und sicherer.
>
> Bevor ich eine neue Version hoch lade, werde ich erst mal ein paar Gemeinden konvertieren und die Ergebnisse prüfen.
>
>
> Frank
>
> [1] http://trac.wheregroup.com/PostNAS/browser/trunk/data/konvert/postnas_0.7/alkis_PostNAS_0.7_schema.sql
>
>
> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Frank
> Gesendet: Mittwoch, 9. Mai 2012 07:51
> An: nas at lists.osgeo.org
> Betreff: Re: [PostNAS] RE: Antworten zu Delete/Replace
>
> Moin!
>
> Hat sich eigentlich mal jemand die Trigger angeschaut?
>
> Ich hatte den gdal-Patch und die Info aus einer Mail mit dem alten Schema zusammen gefügt und das ganze ins PostNAS-SVN gestellt.
>
> Ich habe aber noch nie mit PostgreSQL-Triggern und -Functions gearbeitet. Es könnte sein, dass ich dabei etwas Fundamentales falsch gemacht habe.
>
> Jedenfalls findet der Trigger nicht die zu löschenden alten Objekte.
> (ausführliche Beschreibung in meiner Mail vom 25.04.)
>
> Funktioniert das bei euch, oder nicht?
>
>
> Am 25.04.2012 13:55, schrieb Armin Retterath:
>> Hallo Frank,
>>
>> werde den Patch auch in den nächsten Tagen bei den ATKIS Daten aus RP 
>> ausprobieren. Gebe Bescheid wenn ich was herausbekomme.
>>
>> Gruss
>> Armin
>>
> ...
>>>> -----Original Message-----
>>>> From: nas-bounces at lists.osgeo.org
>>>> Sent: Monday, April 23, 2012 1:50 PM
>>>> Subject: [PostNAS] Fragen zu Delete/Replace
> ...
>>> Die Tests waren noch nicht ganz erfolgreich. Siehe unten.
> ...
>>> TEST:
>>> Variante 2/2a
>>>   .. funktioniert mit meinen Daten NICHT bei 'replace'.
> ...
>


-- 

Mit freundlichen Grüßen

Astrid Emde

********************************************
Where2B Konferenz 2012
13. Dezember 2012 in Bonn
www.where2b-conference.com
********************************************

 Astrid Emde
 WhereGroup GmbH & Co.KG
 Eifelstraße 7
 53119 Bonn
 Germany

 Fon: +49(0)228 90 90 38 - 19
 Fax: +49(0)228 90 90 38 - 11

 astrid.emde at wheregroup.com
 www.wheregroup.com

 Folgen Sie der WhereGroup auf twitter: http://twitter.com/WhereGroup_com

Amtsgericht Bonn, HRA 6788
-------------------------------
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
-------------------------------
 pgp-public key:
 http://pgp.mit.edu:11371/pks/lookup?search=0x06DA52D72D515284
  Signierte und/oder verschlüsselte Nachrichten sind sehr willkommen
  Signed and/or encrypted mail is highly appreciated