[PostNAS] Antworten zu Delete/Replace

[Armin Retterath]

Hi Frank,

danke für die Info. Ich bis dato leider auch noch nicht dazu gekommen, 
die neue Update Funktion zu testen. Bei mir läuft immer noch - shell 
gesteuert - die psql Funktion drüber.
Eigentlich wollte ich die Funktion anpassen.
Wieviel performance Gewinn bringt der Weg über den Trigger beim Import?
Es sollte doch dann um einiges schneller laufen, als wenn man erst die 
Daten importiert und dann die delete Tabelle abarbeitet.

Gruß
Armin

On 29.10.2012 10:30, "Jäger, Frank (KRZ)" wrote:
> 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'.
> ...
>


-- 
Zentrale Stelle Geodateninfrastruktur
Rheinland-Pfalz
LVermGeo-RP

Ferdinand-Sauerbruch-Straße 15
56073 Koblenz

0261/492-466
armin.retterath at lvermgeo.rlp.de
http://www.geoportal.rlp.de