[geotk] Using metadata.sql

[Martin Desruisseaux]

Hello William

I committed a fix and tested that it worked with your metadata (35 tables 
created). If you are using Maven, the fix is available on version 3.x-SNAPSHOT.

Now, when a new metadata is inserted in the database, MetadataWriter will 
initially set the foreigner key constraint to the child table instead than the 
parent table. Then, every time a new metadata is inserted, the writer verifies 
the foreigner key constraints. If a conflict is found, the foreigner key is 
automatically dropped (I forgot to log a warning when such even happen - I will 
do that tomorrow).

Of course verifying the foreigner key constraints on insertion has a cost, but 
this is hopefully not major. Anyway, this hack would completely disappear if 
PostgreSQL supports index inheritance in a future version.

Please let me know if you meet other issue,

     Martin

P.S.: By the way, the metadata file that you provided looks very nice. Do you 
allow us to add it in the Geotk JUnit test suite?


Le 05/04/12 10:15, William Temperley a écrit :
> Dear all,
>
> I'm trying to load an ISO19139 XML file and persist it using
> metadata.sql.MetadataWriter.
>
> I'm loading a file (see http://pastebin.com/FvpDw3Kt) into a
> DefaultMetadata object (which works great, thanks!) but when I attempt
> to persist it using MetadataWriter.add(defaultMetaData), I get the
> following error:
>
> org.postgresql.util.PSQLException: ERROR: insert or update on table
> "EX_Extent" violates foreign key constraint
> "EX_Extent_geographicElement_fkey"
>    Detail: Key (geographicElement)=(FD10C2) is not present in table
> "EX_GeographicExtent".
> 	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2077)
> 	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1810)
> ...............
>
> I'm wondering if perhaps this is due to
> EX_Extent_geographicElement_fkey not being initially deferred?  I
> can't see the schema as the transaction aborts.
>
> I'm on Postgres 8.4.
>
> Thanks and regards,
>
> Will Temperley