[fdo-internals] Standardising FDO Schema's

[Traian Stanev]

I agree with Robert on this one. There's a schema (or schemas). It has a name. It has classes. The classes have names. From the point of view of the FDO client app, those remain consistent within the boundary of the FDO connection.

If the provider is doing some monkeying around with class names that come from the source database, it's the provider's job to be consistent about handling such mangled names. How the provider does that? Who cares, as long as it does?

Traian


From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Friday, August 29, 2008 10:54 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Standardising FDO Schema's

On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <robert.fortin at autodesk.com<mailto:robert.fortin at autodesk.com>> wrote:
As Orest said, FDO represents the data in different layer Datastore, Schema and Class. That's the rule.  That's the standard.
The fact that some provider doesn't have/require schema doesn't mean we don't need a generic schema representation in FDO.  It's up to the provider to say what this schema is named and what it maps to (e.g. default or something else). FDO doesn't impose rules around the name of the schema.

but currently there is no standard implementation pattern! that's the problem!
which means every implementation can be different!

should a fdo client really care about which provider and data source is being used?

Isn't FDO meant to flatten out all these differences...

In Orest's example with the oracle database, the database already exists, with a well known
and understood access pattern right.  the database supports the use of grants, synonyms,
roles etc. there is an existing structure in place.

create user denver identified by datamonkey
grant select on parcels.denver to denver.parcels
and so on

Isn't that a much easier and better place to be managing this kind of thing?

For example, removing the schema from SHP would result that you could have 2 flavors of shp depending on the connection.  Connect to a single file and you get no schema.  Connect to a directory and you get a schema name "default".  SHP provider standardize to using "default" every time.
Also applications relies on that standard: there will be a schema and it will have a name.  This result in consistant representation of the schemas and classes in a tree view for example. Changing this behavior has impacts on applications relying on that standard.

I agree the my suggestion of an empty schema would cause headaches, does FDO have the concept of
a default schema? Ie GetDefaultSchema()? I just know fdo mostly from the mapguide api side of things

standardising along these lines, primarily for databases providers, means that any updating
to support this model would mostly involve removing custom provider specific workarounds....

A lot of applications wouldn't be affected at all, they just pull whatever structure the provider represents.

Those which do, probably have a lot of case statements to handle each different provider's quirks,
which could potentially be deleted.

z



Robert

-----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 Mateusz Loskot
Sent: Friday, August 29, 2008 11:05 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Standardising FDO Schema's

Orest Halustchak wrote:
> [...]
> The above is a logical schema. How could that be mapped to physical
> schema? The discussion started with Oracle. Let's say I have an
> Oracle instance called ORCL. The main physical grouping mechanism
> that Oracle has is an Oracle Owner. So, one mapping is that the FDO
> Data Store maps to Oracle Owner, then FDO Schema.Class maps to table.
> That keeps the integrated set of data within a single Oracle owner.
> Another mapping is to map FDO schema to Oracle Owner, i.e. define
> Oracle owners LANDUSE, TRANSPORTATION, etc. But, then how do we
> separate CityOfDenver parcels from CityOfBoulder parcels? I could
> have DENVER_LANDUSE, BOULDER_LANDUSE, etc. There is a third mapping
> possible, and that's to use a separate Oracle instance for each data
> store, but users may not want to set up separate physical instances
> for this purpose, especially if they have a large number of data
> stores.


Orest,

Thanks for the very in-depth explanation of schema naming issues.

But we still need a consistent way to define and describe all
possibilities of mapping and naming paths in text.
As Zac proves, using only separators (like ::, ~, etc.) is insufficient.

I think more self-describing approach is needed, perhaps we would use
XML or JSON for naming schemas?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
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 (My Blog)
+61 405 847 168
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080829/4a514339/attachment.html