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

Reply via email to