[PostNAS] Antworten zu Delete/Replace

[Astrid Emde]

Sorry,

hatte ein Detail überlesen. Es ist ja ein Trigger und keine Funktion,
die nach dem Einlesen der NBA-Datei aufgerufen wird.

Bitte die vorherige Mail daher ignorieren.

Schönen Gruß

Astrid Emde



Am 29.10.2012 10:57, schrieb 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