[fdo-internals] fdopostgis

[Paul Ramsey]

All,

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

-- 

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   pramsey at refractions.net
   Phone: 250-383-3022
   Cell: 250-885-0632