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 [EMAIL PROTECTED] Phone: 250-383-3022 Cell: 250-885-0632 ------------------------------------------------------------------------- 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
