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. -- Matthias Basler [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
