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 > > !DSPAM:1004,45ac96ec202901510810322! > -- 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
