I intend to finish it Justin. > Can I ask you move it a spike then. This has no path to getting its way > supported, or even really used. Or go ahead and throw it in demo. > > -Justin > > Jody Garnett wrote: > >> I am going to keep on muddling with postgis2 ... >> a) not going to install oracle on my laptop >> b) h2 (while cool) seems to lack index support right now (and I am not >> cool enough to know how to fake it) >> >> Jody >> >>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> >> !DSPAM:1004,45ad23b1298861804284693! >> >> > > >
------------------------------------------------------------------------- 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
