And what are you planning on doing with it after you finish it? Jody Garnett wrote: > 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,45ad290e303442223018498! >
-- 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
