Its an embedded java based database. http://www.h2database.com/html/frame.html
David, I would be interested in hearing your thoughts on the current JDBC datastore api. The general concencus from myself and the other jdbc module maintainers is that it requires some cleanup / re-archtecting, etc... Do you concur? This wouldn't really be something we would force on the current jdbc modules. They work well as written, even if a bit hard to maintain. What we would really like is to have a good example of what a maintainable jdbc datastore would look like. And come up with a high level of test coverage for it. With these in hand, jdbc module maintainers like you and myself would be in a better position to possibly switch over. -Justin David Adler wrote: > What is H2? > > I'm certainly interested in the JDBC and DataStore topic, although > fixing this may be considerable work. > > David > > 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 >>>> >>>> >>>> >>> >>> >> >> ------------------------------------------------------------------------- >> 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,45ae5c21165401336712104! -- 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
