Quoting "P.Rizzi Ag.Mobilità Ambiente" <[EMAIL PROTECTED]>:
> Ok, I thinked about it a little and I came to these conclusions: > 1) The FIDMapper stuff is very involved, like it is involved a good > part > of the JDBCDataStores, SQLEncoders, etc. but nonetheless they work!!! > They can use a good review/rewrite, but nobody has the time/courage > to do it > now, so leave them as they are. > 2) Fortunately, for createSchema() there's no need of a FIDMapper at > all, > all that's needed is: > a) a FeatureType with all attributes, even ones that a FIDMapper > would > hide > b) a String[] with the names of PrimaryKeys attributes > > How a) and b) can be obtained is left as an exercise to client code. > > So I would add to the OracleDataStore a method like this: > createSchema(FeatureType featureType,String[] pkNames) > There's no need to change the DataStore interface, client code will > look > for this method using reflection, and call it if present, otherwise > it > will call the normal createSchema(FeatureType featureType) method > and hope it will work. This sounds fine as a temp solution. > > Yes, it is a quick and dirty solution, but it's what I need now. > The real hard work will go in the SQL generation for OracleSDO. > > I'm also thinking that the FIDMapper stuff may go away with the work > for the ComplexDataStore/FM/complex_sco or whatever it is exactly > called. > If I got it well a good part of it is about mapping between a > physical > data source (like tables in a RDBMS) and an external schema. > So for a future and robust createSchema(), we'll need to keep in > consideration this mapping. Yes, I very much agree that fidmapper _should_ not be needed when we get the full mapping system. Indeed in many ways it's the expansion of the fidmapper system to all potential columns, with even more control. I'm pretty sure Gabriel is on the same page as well... > > For now, let's assume that createSchema() needs the "physical" > schema, that > is the one with all the attributes present, > even the ones a FIDMapper would have hidden. > > Does this makes sense??? Yes. Chris > > Bye > Paolo Rizzi > > > > > 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. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
