Hi Matthias, You actually make a really good point. One thing we found when implementing the oracle dialect is that we did indeed have to change the interface quite a bit. Once this interface is "out in the field" this will indeed become problematic and we won't have the freedom to change api on the fly.
I guess the idea is that oracle might be a worst case scenario... so the interface as it stands probably encapsulates most stuff needed. As well Christian has done a sanity check against db2 and found some issues there as well. Hopefully this range of implementations can keep us confident enough going forward that the interface won't require changes that are too too drastic. -Justin Matthias Basler wrote: > Justin wrote: >> I have thrown together an official proposal for the new jdbc datastore >> stuff: >> >> http://docs.codehaus.org/display/GEOTOOLS/Next+Generation+JDBC+DataStore >> >> Comments/feedback welcome. > > Since I already have classes in my own code base that account for SQL > dialects I can only say that - as time goes by - I find more and more > differences that must be accounted for. I haven't encapsulated these > vendor-specific helper functions as an interface, rather I use a set of > static singleton classes which I can extend at any time if I find another > case where vendor specific code must be hidden from the rest of the > application. > (They are part of a small library I can use in different projects.) > > Besides it comes to my mind that different vendors's databases produce > different Exceptions/Errors. Being acquainted with Oracle, I often read out > the ORA error code and produce meaningful error messages, e.g. if a column is > not found. > > I am not sure an interface (which by definition shouldn't change too often) > can account for all this. You surely have more experience with the particular > use case of Spatial Data Stores, so if you think you know all the required > "extension points" for vendor specific code beforehand I am fine with this > solution. > > Of course I agree that it would make implementing a new database support much > easier and I am always in favour of less code duplication. > > Just my 2 cents. -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel