I don't have any real objections
to this, though I don't have a vested interest in the PostGIS provider at this
point. It would probably be best to go to the mapguide and fdo users lists
for feedback from real PostGIS users.
The original design decision was
made because we had limited resources after moving away from the initial
decision to implement using the generic RDBMS framework. It was easier
not to support multiple databases (something about ListDataStores, a lack of
cross-database query capabilities in PostgreSQL, getting a bit fuzzy now) and at
the time I didn't have a requirement for multiple databases on the same server,
or cross-schema data access from a single connection.
As a note, I believe that best
practice is not to store the PostGIS support in the public schema, but in an
alternate schema using a search path. I'm not entirely up to date on this
though.
Jason
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak
Sent: Tuesday, July 07, 2009 6:55 AM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: PostGIS provider connection question
Hi,
Does anyone have any
thoughts on the topic below?
Thanks,
Orest.
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak
Sent: Friday, June 26, 2009 11:06 AM
To: FDO Internals Mail List
Subject: [fdo-internals] PostGIS provider connection question
Hi,
I have a concern about the current
connection parameters that the FDO PostGIS provider is using.
The current situation is this.
To make a connection to PostGIS we need to
specify a service and a datastore.
The service is mapped to
database@server:port
And the datastore to
The physical postgis schema
So a typical connection would be
Service :
MyPGDatabase@MyServer:5432
Datastore :
public
But a PostGIS server can contain multiple
databases with each database containing multiple schemas, which contain the
tables. My question is why wouldn’t we set up a connection mapping that
exposes the PostGIS databases as FDO datastores and the PostGIS schemas as FDO
schema, similar to how we do it with SQL Server, which has similar concepts.
So, connection information would be:
Service: server:port,
e.g.
MyServer:5432
Datastore: PG database name, e.g. MyPGDatabase
Then, within that datastore, we have
schemas called ‘public’ and any other schemas that the user has
created there, such as “landbase”, “transportation”,
“utilities”, etc.
I realize that this has already been
implemented and changing this could have some backwards compatibility issues
with applications and MG resource definitions. But, maybe the benefits of
having a better datastore / schema mapping to PG database / schema would be
worth figuring out how to deal with the compatibility issues?
What do you think?
Thanks,
Orest.
