Good Points Andrea; I tried to be clear that I am keeping all the optimizations, workaround etc - I am just making sure each one has a home (using object oriented code for a clear separation of concerns) This helps us manage the problem. Also the separation from the other JDBC DataStores means that the PostGIS code is not required to subclass to disable workaround placed made available for Oracle etc.
If I can sum up the mood as we look at this - it is one of "ack there is a lot of work here" :-) Jody > 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 > ------------------------------------------------------------------------- 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
