[mapguide-users] Some thought on FDO PostGIS Provider

[Gabriele Monfardini]

Hi all,

I am trying Mapguide 2.1 and FDO PostGIS provider (using Maestro 2.0 RC1).

The provider uses the word "datastore" to refer to PostgreSQL schema
(http://www.postgresql.org/docs/current/interactive/ddl-schemas.html).
This is very misleading since there are schemas and tablespaces in
PostgreSQL, but no datastores.
Moreover (this can be a Maestro issue) the default value seems to be
empty instead of "public", that is the default schema present in all
PostgreSQL databases.

Second problem: what is the reason to include the schema in the dataconnection?
I mean, I want to connect to a specific database, not to a specific
schema inside the database.
The schema and the table should be part of layer definition, as in OGR Provider.
This would be better from a logic point of view and I don't know of
any application that requires to specify the schema before connecting
to a PostgreSQL db.

One may think this is a minor issue.
In fact it depends on the size of the repository.

I'm about to migrate from Mapguide 1.2 OGR Provider to 2.1 PostGIS Provider.
I have around 40 databases, each one with 5-10 schemas for a total of
over 1000 layers.
With Postgis Provider I have to create 200-400 dataconnection (instead
of 40) and manually modify all 1000 layers.
The last part is needed since the layer specifies in the FeatureName
the dataconnection provider type (that has to be updated from
OGRSchema:schema~table to FdoPostGIS:table) and from my preliminary
experiments Maestro is not so smart to update the layers when I change
only the dataconnection type, but not its name.

I do not consider this a Maestro issue (in fact its smartness is
already invaluable), but a not so smart decision when designing the
XML schema.
Since the layer specifies the ResourceId, IMHO there is no apparent
need to decorate its FeatureName with dataconnection provider type.
But maybe I'm ignoring something.

I've also probably found a bug in FDO PostGIS provider.
If at least one table in the schema contains a field of type
"timestamp with time zone", the provider is not able to describe the
schema.

Trying to save such a dataconnection into the repository (with
Maestro) or trying to create a layer with this dataconnection leads to
errors in Mapguide 2.1.
Not always the errors are the same (different paths in the code
depending to resource already cached or not?), and I report the three
more commons:

1 -  "describe schema command failed" at
mgdev\server\src\services\feature\ServerDescribeSchema.cpp, line 204

<2010-02-15T18:06:59> 	512	MapGuide Maestro v2.0.0.4569	10.1.1.244	Administrator
 Error: An exception occurred in FDO component.
        The describe schema command failed for 'FdoPostGIS' schema.
 StackTrace:
  - MgFeatureServiceHandler.ProcessOperation() line 83 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\FeatureServiceHandler.cpp
  - MgOpDescribeSchemaAsXml.Execute() line 110 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\OpDescribeSchemaAsXml.cpp
  - MgServerFeatureService.DescribeSchemaAsXml() line 333 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerFeatureService.cpp
  - MgServerDescribeSchema.DescribeSchemaAsXml() line 628 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp
  - MgServerDescribeSchema.DescribeSchema() line 564 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp
  - MgServerDescribeSchema.DescribeFdoSchema() line 204 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp


2 - "Null reference" at
\mgdev\server\src\services\feature\ServerDescribeSchema.cpp, line 77
(not so auto-explaining message for the user)

<2010-02-15T17:50:02> 	2556	MapGuide Maestro
v2.0.0.4569	10.1.1.244	Administrator
 Error: Null reference.
 StackTrace:
  - MgFeatureServiceHandler.ProcessOperation() line 83 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\FeatureServiceHandler.cpp
  - MgOpDescribeSchemaAsXml.Execute() line 110 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\OpDescribeSchemaAsXml.cpp
  - MgServerFeatureService.DescribeSchemaAsXml() line 333 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerFeatureService.cpp
  - MgServerDescribeSchema.DescribeSchemaAsXml() line 628 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp
  - MgServerDescribeSchema.DescribeSchema() line 564 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp
  - MgServerDescribeSchema.DescribeFdoSchema() line 77 file
c:\osgeo\mapguide_21\mgdev\server\src\services\feature\ServerDescribeSchema.cpp


3 - A terrible MgInvalidStreamHeaderException that seems not properly
catched and crashes the server, without logging anything at all.
This seems to happen more often when trying to create the layer
selecting the dataconnection.
This one appears to be a bug in Mapguide.

I've also find a possible bug in Maestro.
When I try to save the problematic dataconnection it warns me that FDO
connection failed and offers to save it anyway. Sometimes, even if I
save it, it does not record correctly the Datastore, leaving it empty
in the XML.

Last "rant".
Why OGR is no more built by default with PostGIS support?
It would have provided me a much more smooth upgrade from 1.2.
Moreover, FDO PostGIS Provider is quite recent, initially developed
only for Windows, and I suspect not so much used.
Having 2 possible connection to PostGIS would offer the possibilities
to compare the performances (that in my situation are very important)
and choose the best one.

I am not so happy to drop here and there new dlls, also because in my
experience MG is quite strict on library versions, and at least
version 1.2 quite poor on logging useful information. So this could
lead to not-logged crashes or generic errors that are very difficult
to solve.

That said, if you know an URL with OGR dll compiled with PostGIS
support, in a version compatible with Mapguide, I would rather try
them, before starting editing the 1000 layers...

Regards,

Gabriele Monfardini