If someone has some suggestions for re-architecting the JDBC interface,
I am certainly willing to review and comment but I don't have the time
to lead something like this.
Working with the current JDBC classes has been a pain but everything
seems to be mostly working at this point. I'd rather see the SQL
generation that is in the FeatureWriter classes consolidated in
SQLBuilder. The use of schema name prefixes for table names is
inconsistent as is handling case-sensitivity of table, column and other
object names. Relationships of FeatureTypeHandler, FeatureTypeInfo and
JDBCnDataStore are not the cleanest.
It would be helpful if there was some documentation on the
responsibilities and relationships of the various JDBC classes. Does
this exist someplace? I would almost be surprised if it did ;-)
Justin Deoliveira wrote:
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
Geotools-devel@lists.sourceforge.net
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:1004,45ae5c21165401336712104!
|
