[fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming Conventions

Thu Oct 29 09:32:47 EDT 2009

Hi Zac,

Yes, something like this would have to be a separate RFC.

Thanks,
Orest.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Wednesday, October 28, 2009 9:21 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming Conventions

sounds like another RFC ?
On Thu, Oct 29, 2009 at 1:04 AM, Orest Halustchak <orest.halustchak at autodesk.com<mailto:orest.halustchak at autodesk.com>> wrote:
Hi,

I'd also like to add a comment about something that Haris said in a separate reply.

>  Perhaps, providers could return additional info about names of newly created classes.

I think that's a good idea, maybe a way for ApplySchema to return information about anything that was changed from the user's input.

Thanks,
Orest.

From: fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org> [mailto:fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org>] On Behalf Of Orest Halustchak
Sent: Wednesday, October 28, 2009 9:39 AM

To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming Conventions

Hi Zac,

FDO does have a concept of datastore. There are FDO commands to create, destroy, and list datastores. A datastore is also what you open with the connection command. It plays a role. My example is meant to show a case of two separate FDO datastores that for an rdbms are managed by one rdbms server.

Thanks,
Orest.

From: fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org> [mailto:fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org>] On Behalf Of Zac Spitzer
Sent: Wednesday, October 28, 2009 9:15 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming Conventions

inline

On Wed, Oct 28, 2009 at 11:56 PM, Orest Halustchak <orest.halustchak at autodesk.com<mailto:orest.halustchak at autodesk.com>> wrote:
Hi,

Note that there is another qualifier that should be taken into account in these discussions and that is the datastore name. There are really three levels of qualification: datastore name, schema name, class name. So, cases where it is suggested to use the file name as the schema name, if the file name is already used for the datastore name, it doesn't have to be used again for the schema name.

My understanding is that FDO has no concept of datastore, it starts with schema's

datastore is defined at the FDO connection level, why squeeze three levels into
a two tier structure?

An issue with rdbms is that some such as SQL Server include the three levels of database, schema, and table. Others such as Oracle do not. So in the Oracle case if we map the datastore name to the Oracle user/schema, then we should not also use Oracle user/schema for FDO schema.

Consider this example.
       FDO Datastore = CityOfNewYork
               FDO Schema = LandBase
                       Class = Parcel
                       Class = Road
               FDO Schema = Water
                       Class = Pipe
                       Class = Valve
               FDO Schema = Gas
                       Class = Pipe

       FDO Datastore = CityOfAlbany
               Same schemas and classes

We don't want to mix up the parcels from CityOfNewYork with the parcles from CityOfAlbany, those should be in separate tables. Having the Oracle schema name as LandBase, Water, and Gas doesn't handle this.

but that is a problem already solved when you follow the other way other
database access layers work????

based on the connection details, either by specifying a datastore, or not
Pipe would only be accessible if it was the default for the user or the for
specified datastore. There is a implied concept of the default schema?

if there's no default and two schemas means there are no schema less tables
to enumerate

This is how databases normally work in my experience which is all I'm trying
to suggest with this RFC.
Also, about the ~ColumnName convention being used for geometry columns, note that FDO does allow more than one geometry column per class with one flagged as the main geometry. I wouldn't want to require that these have to be exposed as separate feature classes.

Thanks,
Orest.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org> [mailto:fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org>] On Behalf Of Haris Kurtagic
Sent: Wednesday, October 28, 2009 6:07 AM
To: 'FDO Internals Mail List'
Subject: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming Conventions

there is another important case which is not covered in RFC.
Same table name in multiple schemas. Also, how to not mess up when users
logs using different credentials.

One way to solve that could be to always use rdbms schema name as fdo schema
name.

I believe it is absolutely necessary that application using FDO to access
rdbms can be sure exactly which table and column it is accessing.
Because what FDO provider sees when connects to rdbms can change regarding
which credentials are used to connect to rdbms. That menas that on same
database it can see only one table, or two tables (same name) in two schemas
or even one or more geometry columns in table.

I am not keen on current naming in King.Oracle with this ~ sign, but I am
very pleased that when using King.Oracle and FDO class trough it, I know
every time exactly which Oracle schema, table and column I am hitting.

Just when wanted to finish something else from RFC:
"Class names for databases are normally tablename, unless qualified which
then has ~COLUMN_NAME appended. (if the are multiple geometries, FDO
requires to know which one is the identifier)"

In King.Oracle ~COLUMN_NAME is appened to make sure resulting name would be
unique. Which actuall oracle column is used is not parsed from name of class
but it is kept inside provider. ~COLUMN_NAME could be anything.

Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org<mailto:mapguide-internals-bounces at lists.osgeo.org>
[mailto:mapguide-internals-bounces at lists.osgeo.org<mailto:mapguide-internals-bounces at lists.osgeo.org>] On Behalf Of Zac Spitzer
Sent: Wednesday, October 28, 2009 9:45 AM
To: FDO Internals Mail List; MapGuide Internals Mail List
Subject: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming
Conventions

I have posted RFC 43 for review

http://trac.osgeo.org/fdo/wiki/FDORfc43

--
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org<mailto:mapguide-internals at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/mapguide-internals

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/fdo-internals

--
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/fdo-internals

--
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20091029/cee46548/attachment-0001.html