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. 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. 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??? 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
