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
|
