Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view


Paul Ramsey-2


After thrashing about for a while on developing our FDO provider
templating off of the MySQL provider, and using the Generic RDBMS
interfaces we have decided to take a new tack.

I am cc'ing this to Geotools, because deep in their designy hearts they
appear to still hold onto the same core belief, that databases are
similar enough that doing an abstract database layer between the
abstract datastore implementation and the specific database
implementation will save more work in shared functionality than it will
generate in specializations.

Having now seen this pattern in two different projects, I do not think
it is so anymore.

Our experience in PostGIS FDO has been that of either (a) having to
bring in specializations due to slightly different implementations than
the Generic writer expected and (b) inheriting some
lowest-common-denominator assumptions that we did not really want,
brought into Generic because of which specific databases got implemented
first (MySQL, ODBC).

The experience in Geotools has been, instructively, quite similar.  An
examination of the actual PostGIS Geotools implementation at this point
will find a good deal of sub-classing and re-implementation of
supposedly generic things back down inside the PostGIS datastore.  This
is theoretically all well-and-good... reuse what you can, reimplement
what you must.  But the long term effect is to make the entire structure
brittle... what do you do when you find a bug in the abstract database
level? Fix it, and you could break workarounds throughout the
implementations.  Leave it, and...

It seems like a far more efficient system would simply have one "well
structured, high quality" example on a "relatively standard" database,
and let new implementors do code re-use through simple copy-and-paste.
Then you could be assured that the implementations will converge on
quality over time, and that people mucking about in the superclass layer
cannot accidentally break implementations.

All this to explain, that we are going to move from postgis support
being in fdordbms to it being a separate fdopostgis provider, in the
style of the King Oracle provider.

We will be working in our own repository in the short term, because we
need to get started, but hope to have a slot in the FDO repository once
the reorganization is complete.



   Paul Ramsey
   Refractions Research
   [hidden email]
   Phone: 250-383-3022
   Cell: 250-885-0632
fdo-internals mailing list
[hidden email]