Quoting "P.Rizzi Ag.Mobilità Ambiente" <[EMAIL PROTECTED]>:
> > 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. > Currently existing FIDMappers can't work without the FeatureType > beeing already present, so the above method would not be an override > of the default one, but the only working possibility. > It may apply to non-JDBCDataStores as well, they could simply > ignore the PKs if they have no notion of them. > Or we may design a mechanism where FID mapping meta info are > stored somewhere "along" a DataStore's data. This way we would > be able to store PKs even for DataStores that don't natively support > them. I think this actually speaks to the need for the FeatureTypeInfo meta class to go into GeoTools. I forget what you call it in udig, but it has the same concept. It sounds like the time to do this is now, since we've got the new catalog in place. If done right it should be very extensible, allow people to throw whatever metadata they want into it, like primary key information, and to put in and get out the abstract, keywords, constraints, ect. that we need in geoserver. And ideally to be able to derive such properties from setting like an ISO 19115 file in the metadata, and to also derive as much as possible from metadata files that might be included with certain data formats, like the shapefile.xml thing. Thinking on Dave asking about primary keys in GML, in GML3 I'd guess the closest thing is the gml:id, which is an expansion of the fid of gml2. You can use the gml:id things like foreign keys, refering to the ids from other places, I'm pretty sure. So it would seem that they could reasonably be primary keys. Where they all a bit short compared to a db, however, is type information. They are of type xml:id, which I think is just a string, which in xml means 'anything'. In a db you can set the type of your primary key, and indeed it's very useful to constrain it to be an integer so you can have it auto-updating and the like. I suppose we could sorta hack gml and make an extension of gml:id that limits it to an integer, but I think it'd be easier to just do it at the code level, carry it in featureTypeInfo, as I think there were always be at least a bit of datastore specific information that we can't fully capture in our type system. Though I only feel comfortable about adding FeatureTypeInfo after we have the new feature model, so that we don't just get lazy and put all the meta information there. > But this is something that would have a much broader impact. > Also the FID mapping is just one of many possible mapping issues > between the logical FeatureType and it's physical representation > by a DataStore, so it should be addressed as such. For example the > ComplexDataStore by Gabriel may come to a rescue here. Yes, exactly. Our meta information hacking should come after addressing the broader issue of featureType mapping. Chris > Bye Paolo > > > > > > 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 > > > > > > > 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 > ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ ------------------------------------------------------- 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
