[PostNAS] Fwd: Re: [GDAL] #4555: NAS: better support for wfsext:Replace

[Jürgen E. Fischer]

Moin Astrid,

On Mon, 12. Mar 2012 at 08:49:30 +0100, Astrid Emde wrote:
> dein GDAl patch wurde angenommen und eingebaut.

Jau, Even hat's in r24105 in Trunk commited.


> Vielen Dank für die Neuerungen.  

Bitte schön.


> Damit sollte auch das Ticket #16 (Delete-Tabelle neue Spalte Typ für update
> oder delete) [1] geschlossen werden können, oder?

Da geht's ja eher um das Löschen.  Wenn ich mich nicht irre, wurden delete
Sätze für Replace schon vorher geschrieben.  Allerdings wurde der Kontext
(Delete/Replace) und der Hinweis auf das ersetzte Objekt (zumindest dessen
Timestamp - es ist ja immer(?) das selbe Objekte) ging verloren.

Außerdem löscht 'mein' Trigger nichts mehr, sondern setzt nur das - ebenfalls
neue - "endet" Feld auf einen Wert:  Im Fall delete auf die aktuelle Zeit und
im Fall von Replace auf das 'beginnt' des ersetzenden Objekts.

Nachträglich Löschen könnte man immer noch, muß man aber nicht zwingend - man
kann auch die komplette Historie stehen lassen und überall wo nur der aktuelle
Stand interessiert "WHERE endet IS NULL" ergänzen.


>    Hast schon jemand die Neuerungen getestet?
 
>    Nun ist die Frage, ob sich auch noch an dem SQL-Schema [2] und in der
>    Dokumentation [3] Änderungen ergeben?

Das ist ja der PostNAS-Teil des Patches. Neben dem Trigger wurde noch:

- ein "endet"-Feld ergänzt und "beginnt" in das Unique-Constraint gml_id
  übernommen
- ein "identifier"-Feld ergänzt, in dem der komplette ID inkl. Timestamp-Platz
  findet,
- direkten Änderungen an geometry_columns und den dazugehörigen Constraints
  entfernt und gegen AddGeometryColumn ersetzt (mit PostGIS 2.0 wird ersteres
  nicht mehr gehen).
- einige Längenbeschränkungen bei varchar-Feldern entfernt
- Kosmetik: character varying durch varchar ersetzt.

Ich habe das ursprünglich auch auf einer älteren Version gemacht und ich
vermute, dass sich beim Übertragen auf 0.7 auch noch einige Fehlerchen
eingeschlichen haben.  Vielleicht sollte man die allgemeinen Indizes und
Contraints mit so etwas wie alkis_update_schema() setzen...

Bei der Gelegenheit:  gibt es eigentlich eine "laufende" Version des Schemas im
SVN mit kompletter Revisionshistorie - damit hätte ich wahrscheinlich leicher
mergen können...

Das delete_feature() nun ein Trigger ist, sollte man noch in der Dokumentation
berücksichtigen.  Falls man mit Historie arbeiten möchte, braucht man sich
um "Delete" nicht mehr gesondert kümmern.

Falls man nur die aktuellen Sätze in der Datenbank haben möchte, müßte man noch
eine entsprechende Funktion ähnlich dem alten delete_feature() machen.

> Hast Du schon Zugriff zum Trac/SVN?
 
Ich glaube nicht.


Jürgen

-- 
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-20
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +49-4931-918175-50
Software Engineer         D-26506 Norden               http://www.norbit.de

-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502