[fdo-internals] FDO PostGIS provider developments

[Zac Spitzer]

2009/12/1 Haris Kurtagic <haris at sl-king.com>:
> Is it necessary to replace current version, can't that be another version of
> provider ?
> I was never able to get comfortable with generic rdbms stuff. In my opinion
> there are minuses too.

like?

> I would like to have option of current code base to be continued if there
> would be option at least for some time.
> Haris
>
> On Mon, Nov 30, 2009 at 2:14 AM, Orest Halustchak
> <orest.halustchak at autodesk.com> wrote:
>>
>> Hi,
>>
>>
>>
>> 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.
>>
>>
>>
>> So, what we would like to do is complete our work to get a working PostGIS
>> provider and then replace the current open source code with our new copy.
>> 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.
>>
>>
>>
>> We’ll need to submit an RFC for this, but we wanted to get this
>> information out to you ahead of time.
>>
>>
>>
>> At the same time, we are planning to change the connection parameters to
>> separate out the database name from the service name. This will make it
>> easier for users. They can identify the service (e.g. localhost:5432), and
>> then see the available datastores from which they can choose in a UI. 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.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Orest.
>>
>>
>>
>> _______________________________________________
>> fdo-internals mailing list
>> fdo-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>>
>
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>



-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168