I think you are exactly right Chris. The first round of jdbc helper classes were written at a time when postgis was young. And it kind of evolved on a need by need basis as postgis required. Or so i can infer, i wasn't around at that time :).
But now things are pretty stable and we can actually design a nice "internal" api for jdbc datastore developers. I think its a great way to help improve datastores like oracle which suffer from just being a spinoff of postgis. Postgis however will have to come with time, at a point when we have better testing in place to ensure that we can catch all the optimizations and special cases. -Justin Chris Holmes wrote: > Yeah, that sounds ideal. The abstract JDBC infrastructure is obviously > hosed right now - the reality of working with it ends up making things > more difficult due to the amount of hacks to get the subclasses working. > > I agree that H2 would be a great time to have another go at JDBC helper > methods or abstract methods that are actually useful and don't impose a > burden. I imagine that a couple abstract helper methods might still be > useful, but that much of what we try to do is likely better off in some > utility classes. We've had a lot of good lessons, and we should try to > learn from them, make it easier for others to write new jdbc datastores. > Should definitely talk to David Adler as well, he had some ideas on how > to make it easier as well. If we build a nice infrastructure it should > be relatively easy for existing datastores to port over if they choose. > > Chris > > > > Justin Deoliveira wrote: >> Hi Andrea, >> >> Thanks for your thoughts. About PostGIS, originally rewriting it seemed >> like a good idea. But for the exact same reasons you listed. Reproducing >> the functionality while making the code cleaner is no simple task. Part >> of making the code cleaner is getting rid of some of those hacks, which >> then changes the datastore. For these reasons, I dont think its >> realistic to take on this kind of effort. >> >> However, what I would really like to see is a good abstract JDBC >> datastore. One made with the intent to extended. Breaking out "template" >> methods where needed, making it final if need be, etc... >> >> It seems like there is a fair amount of interest in having an H2 >> datastore. I was thinking this might be a much more logical candidate to >> do this type of thing with, since there are no pre-existing expectations >> to live up to. >> >> -Justin >> >> Andrea Aime wrote: >>> Hi, >>> two things Jody said during yesterday IRC meeting made >>> me think tonight. >>> >>> I don't have the logs for the pre-meeting, but the first >>> one was something like how deep is the level of optimizations, >>> workarounds and details in the postgis data store, and how >>> nice is the new experimental one. >>> >>> The old one is ugly, no doubt. Making a new one with a cleaner >>> structure is a good move for long term mantainance. I agree >>> on this too. >>> Yet, the "level of optimizations, workarounds and details" >>> is what makes the postgis data store our best jdbc data store, >>> that is, something that most of the time just works fine, >>> with whatever load of data you throw at it, and with various >>> levels of badness handled transparently. >>> >>> What I would like to make people appreciate is the amount >>> of work that went into the old ugly data store, days of fine >>> tuning, bug fixing that are not evident and not checked by >>> just the unit test suite. Making a new one that passes the >>> same tests as the old one is just a first step towards something >>> that can be used as a replacement. >>> Before venturing into such a change, one has to understand >>> intimately the old and ugly one, appreciate the why and the hows >>> things were done in a certain way. >>> >>> As an alternative, that may work on widely used modules, check >>> out the list of closed bugs on the module and ask yourself whether >>> there is a test for them, and whether the new module exhibit >>> the bad behaviour described in there. >>> If we all added a junit test for each bug found, that would not >>> be necessary, but since history proves otherwise, it's an >>> exercise everyone doing big changes should try out. >>> >>> This is not to say that we don't need change. We do. >>> But we need a change that provides improvements, not regressions. >>> A big changes that disregards detailed correctness and performance >>> issues is a sample of the "small blanket" problem, >>> you try to cover your shoulders, and end up with cold feet. >>> >>> So every time you work on a big change, think about it also >>> from this point of view :-) >>> >>> Cheers >>> Andrea >>> >>> ------------------------------------------------------------------------- >>> >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to >>> share your >>> opinions on IT & business topics through brief surveys - and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> >> >> > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
