[fdo-internals] Standardising FDO Schema's

Wed Sep 3 06:40:20 EDT 2008

Hi Orest,

I would like to add my point here. I think naming or adding db schema
name or column name to FDO class name doesn't have anything to do with
FDO capabilities, architecture, etc... Such method was choosed to get
unique FDO class name, nothing more. Name could be any kind of random
generated character string (while it is unique inside schema).

As you said FDO class supports many geometry columns as properties and
has main geometry property. As far as I can remember it doesn't work
well with client like MG. I can't remember all issue I had, I think one
of them was spatial context. To fully support "choose any geometry
property" concept then it should not be main geometry property for FDO
class.

I run into this naming problems across providers while writing Fdo2Fdo
as well as providers. 

For Oracle provider we have metadata table for KML it is configuration
file.

My thinking was that solution would be (again) FDO application layer. In
that middle level between application and provider such name overrides
would occur.

Haris

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Halustchak
Sent: Tuesday, September 02, 2008 10:15 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Hi,

I don't have a problem with defining some simple conventions such as a
default schema name if one isn't specified explicitly, especially if
it's a generic issue.

However, regarding the geometry property example in the discussion where
'~GeomColName' is appended to the class name, there is another approach.
FDO allows for more than one geometry property in a class. There is one
that is tagged as the main geometry, but there can be others in the
class. It's not a common case, but I have seen examples where additional
geometry properties provide additional information for label points,
schematics, or other things. So, it is valid to generate a single
feature class from an rdbms table that has more than one geometry
column. Some providers have chosen to generate separate feature classes
with only one geometry property per class. In some ways, that is easier
for a client application to deal with, but is not an FDO restriction.
MapGuide Studio, for instance, allows you to choose which geometry
property to use when creating a layer from a feature class definition.

FDO has a component for physical schema overrides that was meant to help
the user with mapping the fdo logical elements with a data stores
physical elements. I suspect that fdo users and developers may not be
finding this that helpful as currently specified. Maybe we need to look
at this in conjunction with the other schema mapping discussions to see
if improving this may help the current issues. The theory was that it
would provide users with a way to add explicit mapping from classes and
properties to physical elements such as tables and columns for rdbms'
and also to be able to identify physical elements from the logical
elements when accessing existing schema. However, because the physical
aspects of data stores are specific to the particular formats, these
overrides were provider-dependent, with provider-dependent api, hence
not easy to use with a general client application. Providers that
supported this override saved the override mapping information in
metadata tables or a configuration file. Finding a more general way to
do this by not using provider specific api's might make this much more
usable. I wonder if anyone has thoughts on this.

Thanks,

Orest.

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

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> 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] 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
	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 (My Blog)
+61 405 847 168

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20080903/218a6cde/attachment-0001.html