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

Zac Spitzer zac.spitzer at gmail.com
Thu Oct 29 20:09:54 EDT 2009


Hi Orest,

comments in line

On Fri, Oct 30, 2009 at 12:20 AM, Orest Halustchak <
orest.halustchak at autodesk.com> wrote:

> Hi Haris,
>
> Yes, datastore is identified at the connection. So, I probably shouldn't
> have used the term "qualifier" for datastore, but maybe grouping mechanism.
> Datastore contains schemas, which contain classes. You connect to the
> datastore and then have access to the schemas and classes within that
> datastore.
>
> >From the FDO developers guide, datastore is defined this way: "A data
> store is a repository of an integrated set of objects. The objects in a data
> store are modeled either by classes or feature classes defined within one or
> more schemas."
>
> For the SQL Server case, a SQL Server database matches well with FDO
> datastore. Tables within an SQL Server database are qualified by a schema
> name. The default is "dbo", but you can define your own. Thus, we can match
> SQL Server schema with FDO schema and SQL Server table with FDO class. So,
> in my example, CityOfNewYork and CityOfAlbany can be captured as SQL Server
> databases and that's how the SQL Server Spatial provider handles this.
> PostGIS also has a similar physical structure, although the FDO PostGIS
> provider currently does not take advantage of it and I think that's a bug.
>
> For the Oracle case, how do you capture separate FDO datastores within an
> Oracle instance? The main grouping mechanism within an Oracle instance is an
> Oracle owner (Oracle confuses things by using terms 'owner', 'user', and
> 'schema' for almost the same thing). So, if we use that grouping mechanism
> for FDO datastore (else how do we handle multiple datastores within an
> Oracle instance) and we map FDO classes to Oracle tables at the bottom end,
> then we are missing a way to represent FDO schemas unless we add some
> additional metadata to track that mapping. Without that mapping present,
> then we can default to only a single FDO schema per datastore. An issue with
> using Oracle schema for FDO schema is how would you distinguish between
> CityOfNewYork.LandBase from CityOfAlbany.LandBase?
>

can you elaborate on "separate FDO datastores within an Oracle instance"

I'm only familiar with a single oracle instance having
(users/schemas/owners),
are you referring to datastores via meta data?

CityOfNewYork.LandBase from CityOfAlbany.LandBase would be seperate schema's
and the unqualified LandBase would only refer to the Default Schema ie the
connected user?

z


>
> Thanks,
> Orest.
>
> -----Original Message-----
> From: 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 4:20 PM
> To: 'FDO Internals Mail List'
> Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard
> FDO Class Naming Conventions
>
> Hi Orest,
>
> I maybe wrong, but would like to clarify it with you. Datastores are
> introduced basically with metadata tables describing fdo classes. So in
> that
> sense I understand that in one database we could have multiple datastores
> but trough metadata tables. With concept of what later called "native"
> database classes there are no datastores ? That is my observation and same
> time question to you.
> Similar, regarding SQL server eventually we don't have database as level,
> because database is defined in connection string, right ?
>
>
> I agree about separate fdo classes for tables with multiple geometries, it
> would be nicer to have one class with multiple geometries.
> But, I think some APIs and even FDO based applications are making
> assumption
> about that one geometry is "main geometry".
> There is no way that provider could construct FDO class from such table, to
> know what is main geometry (without metadata).
>
> Haris
>
> -----Original Message-----
> From: 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 1:57 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard
> FDO Class Naming Conventions
>
> 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.
>
> 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.
>
> 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] 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] 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
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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 -
http://zacster.blogspot.com
+61 405 847 168
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20091030/126a2927/attachment.html


More information about the fdo-internals mailing list