= FDO RFC 45 - Add new FDO PostGIS Provider =

This page contains an change request (RFC) for the FDO Open Source project.  
More FDO RFCs can be found on the [wiki:FDORfcs RFCs] page.


== Status == 
 
||RFC Template Version||(1.0)|| 
||Submission Date|| Dec. 10, 2009 ||
||Last Modified|| Orest Halustchak [[Timestamp]]||
||Author||Orest Halustchak, Badreddine Karoui, Brent Robinson||
||RFC Status||Ready for Review|| 
||Implementation Status||Adopted||
||Proposed Milestone||3.5.0.0||
||Assigned PSC guide(s)||Orest Halustchak||
||'''Voting History'''|| ||
||+1|| Orest, Greg, Frank, Jackie, Traian ||
||+0|| Haris, Jason ||
||-0|| ||
||-1|| ||
 
== Motivation ==

This RFC adds an alternative version of the FDO PostGIS provider that is based on the generic RDBMS framework. The existing PostGIS provider will remain. Both versions will be included for FDO version 3.5.

Autodesk has had interest from Map3D customers who want to use the FDO PostGIS provider to access and edit data using Map3D and other products.

These customers have not been able to use this provider reliably with Map3D. We had a close look at the provider code to determine what work would be needed to complete the implementation of schema and edit support and fix other issues. Unfortunately, we found that the provider as it stands today requires a lot of work to complete the implementation of required FDO interfaces and to add good unit test coverage. Things that still need a fair bit of work include:

 * Creating new schema and new datastore
 * Spatial filter handling
 * Huge memory leaks on insert.
 * Not all schema commands are implemented.
 * Enable and fix transaction support.
 * Constraint and default values support.
 * Lots of TODOs spread all over the code
 * Virtually no unit tests exist.

We looked at the level of effort needed to complete that work. It was quite high. So, we looked at an alternative. There exists an earlier open source community code base for a PostGIS provider that was started a couple of years ago but not finished. That code base used the generic rdbms framework that is shared with the SQL Server Spatial, MySQL, and ODBC providers. Most of the schema processing is handled with that shared code. We spent some time working with the current provider and the other code base to determine the most efficient way to get to a completed provider that would be robust, perform well, and be maintainable.

In the end, we determined that taking the earlier code base, adding support for the recent fdo interface changes, and completing other parts that weren’t finished would take much less time. Also, based on performance comparisons, we would get something that was much faster on inserts and selects, e.g. the select performance is about six times faster and schema describe is about three times faster. We couldn’t compare insert times very well because the current provider kept crashing after a certain point and we couldn’t insert a large number of features.

== Overview ==

This RFC proposes a new FDO Provider for PostGIS based on an earlier code base for FDO PostGIS.

== Proposed Solution ==

What we would like to do is complete our work to get a working PostGIS provider and then add it as a new PostGIS provider, keeping the existing one in place. The new provider will be called OSGeo.PostgreSQL to distinguish it from the current OSGeo.PostGIS.

Note that we plan to use native PostGIS schema without adding additional metadata tables just as the current provider does. It will be able to read any schemas created by the current version of the provider and itself will generate generic PostGIS schemas.

This provider will support the requirements outlined in the initial PostGIS RFC: [http://trac.osgeo.org/fdo/wiki/FDORfc3]. The restriction of requiring only lower case class and property names will be lifted. Inheritance support will be added using native Postgres table inheritance.

At the same time, we are planning to change the connection parameters to separate out the database name from the service name and support a two stage connection. This will make it easier for users. A UI could let the user identify the service (e.g. localhost:5432) and then show the available datastores from which they can choose. Then, PostGIS schema simply will map to FDO schema. The main drawback to this is that any users with existing MapGuide feature sources and layer definitions will have to update them.

In the end, we will end up with a good functioning provider that performs well.

This RFC also requests that the PSC review the status of these two versions of the PostGIS provider periodically to determine which one is being used by the community so that at some point we get back to one supported version of this provider. In the interim, users can try out both versions.



== Test Plan ==
Unit tests to test the provider will be included.

== Funding/Resources ==

Autodesk to provide resources / funding.