P.Rizzi Ag.Mobilità Ambiente wrote:
The problem I am seeing is that teh fidMapper is being used when a table
does not exist. This is the comment from the Jira Task you created:
"The createSchema() function of the PostgisDataStore doesn't work. First
it checks to see if the table to be created is not already present, but then it asks the FIDMapper for the table's PKs. The org.geotools.data.jdbc.fidmapper.getPkColumnInfo() throws a SchemaNotFoundException that cause the createSchema() to fail.
A solution would be to return a new ColumnInfo[0] instead, so that the
buildNoPKMapper() function would be called.
The problem is that FeatureType and AttributeType have no notion of PKs,
so how can the buildNoPKMapper() function knows which fields are Pks???
I have a fixed version of PostgisDataStore (albeit it's not general enough to be used as is). Where and how can I submit it???"

Which is the exact problem I am having. Does your version of PostgisDataStore solve this?

Justin

In fact the FIDMapper shouldn't be involved at all,
but I found the code in that state months ago and
I didn't realize that.
My version of the PostgisDataStore solves the problem by
using a patched FIDMapperFactory and our own Meta Engine
to get PKs info from.
Anyway the clean solution should be to completely remove
the call to the FIDMapper stuff, since it has no sense.
Then we could add a method like this:
   createSchema(FeatureType schema,String[] PKs)
and leave to the client code the burden of specifying
the names of AttributeTypes that are to be used as PKs.
Then the "normal" createSchema() could just call:
   createSchema(schema,new String[0])
I did this for the OracleDataStore and it seems sensible.
I also have a little reflection code to discover if a
DataStore possess the revamped createSchema() or not,
without the need to add it to the DataStore interface.
I'll try to look better into this tomorrow.

I could go for this, thinking a little about it this may be something that applies to all datastores? Each datastore has a mechanism for generating fids, a method like this:

createSchema(FeatureType type,String[] keys);

Would allow people to override it.

Or it could be something that just applies to the JDBC family of datastores.

What do other people think?

P.S: Fixing the OracleDataStore I discovered a few things
that could be enhanced for the JDBCDataStore family,
so we may consider a little redesign for it,
specifically for the Postgis and Oracle DataStores,
to have them working as one may expect them to.


P.Rizzi Ag.Mobilità Ambiente wrote:



The Primary Keys problem is still there, since there's
no notion of them in GeoTools but, apart from that, the createSchema() should work.
Anyway I always used my own modified version of the
PostgisDataStore that has its own metadata support for PKs,
so I'm not sure if the "normal" PostgisDataStore.createSchema()
actually works. You can try it and see what it does.
The case-sensitiveness bugs should have all been fixed.
Anyway I recently started an implementation of createSchema()
for the OracleDataStore with a different solution for the PKs
problem, so I may be able to port it to the PostgisDataStore too.
I have to find time to look into this better. I'll let the list
know when I come up with a solution.

Bye
Paolo Rizzi


-----Original Message-----
From: Tom Howe
To: [email protected]
Sent: 09/11/2005 19.38
Subject: [Geotools-gt2-users] problem creating schema in postgis

Hi,
I saw a message on the list from january that said that createSchema()
for the postgis data store doesn't work.  Is this still the case?

Thanks,
Tom


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users




AVVERTENZE AI SENSI DEL D. LGS. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o

nel/i

file/s allegato/i, sono da considerarsi strettamente riservate. Il

loro

utilizzo è consentito esclusivamente al destinatario del messaggio,

per le

finalità indicate nel messaggio stesso. Qualora riceveste questo

messaggio

senza esserne il destinatario, Vi preghiamo cortesemente di darcene

notizia

via e-mail e di procedere alla distruzione del messaggio stesso,
cancellandolo dal Vostro sistema; costituisce comportamento contrario

ai

principi dettati dal D. Lgs. 196/2003 il trattenere il messaggio

stesso,

divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo,

od

utilizzarlo per finalità diverse.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.

Download

it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users






--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to