[fdo-internals] FDO PostGIS provider developments

[Haris Kurtagic]

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.
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20091130/aada90d2/attachment-0001.html