[fdo-dev] fdo 3.2
Haris Kurtagic
haris at sl-king.com
Thu Oct 26 12:19:09 EDT 2006
Thank you.
Sometimes I use this mailing list not only to discuss how things are
working now, but also to open talk what I or I ran into situation's
while using FDO, hope that is ok.
In King.Oracle besides trying to do without metadata as much as possible
I have plans to support it also.
I would like to support Autodesk FDO Metadata for Oracle. I suppose this
is ok, in sense of licensees, open source etc ?
Thanks,
Haris
________________________________
From: Brent Robinson [mailto:brent.robinson at autodesk.com]
Sent: Thursday, October 26, 2006 6:07 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] fdo 3.2
See inline ,,,
-----Original Message-----
From: Haris Kurtagic [mailto:haris at sl-king.com]
Sent: Wednesday, October 25, 2006 2:09 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] fdo 3.2
Yes, I understand and I am using it in that way in provider.
What I wanted to know is to get info when one provider executes apply
schema, in some way what it has done.
Example would be when you copy schemas and features from one to another
provider and names changes (for that or another reason, provider
implementation or allowed characters or..).
I would like to find which class was created for which .
In that discussion we came to Schema Mapping.
But, if I understand correctly, Schema Mapping is strictly for provider
overrides and you can't use it for
general non-provider specific way.
For example I can't via schema mapping ask provider (non-specific one)
like which logical schema names are mapped into which physical schema
names etc..
Right. Almost all of the current providers, that support ApplySchema, do
not rename any of the schema elements, so a mechanism to get the
original names was never put in place. It would be possible but would
take some work to add this mechanism. Currently,
FdoPhysicalSchemaMapping does not provider a generic way to navigate to
the class and property mappings, since some providers do not define any
overrides for properties. Generic navigation would need to be added to
allow the client to check each schema element for renaming. Also,
current clients (Map and MapGuide), would need to change to take
advantage of this.
I'm not sure if there are any other gotchas with renaming the schema
elements on ApplySchema. However, it might make it more complicated to
round-trip schemas between two datastores or between a datastore and a
UML tool.
The RDBMS and SDF providers avoid the renaming, on ApplySchema, by
storing the schema element names (and mappings to corresponding physical
elements) in metadata in the datastore. If you eventually need to add
metadata support to the King Oracle provider, that might be the way to
go, since the need to rename the schema elements disappears once
metadata handling is in place.
I hope this is not to complicated written, I am running out of my
English :)
Haris
________________________________
From: Brent Robinson [mailto:brent.robinson at autodesk.com]
Sent: Wednesday, October 25, 2006 7:56 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] fdo 3.2
Hi Haris,
The Schema Mappings tend to be provider-specific, since they map feature
schema elements onto physical elements for the provider. There aren't
any mappings common to all providers, for example, the Raster Provider
maps elements onto files while the RDBMS Providers maps them to tables
and columns. Some providers, such as SDF, don't have any overridable
schema mappings. Therefore the FdoPhysicalSchemaMapping class doesn't
contain much other than schema name and provider name. Getting to the
actual mappings requires knowledge of the provider's implementation of
FdoPhysicalSchemaMapping.
There is a lot of commonality between the RDBMS providers so there is an
FdoRdbmsOverrides package where the common mappings are defined. A lot
of the schema mappings for RDBMS providers can be retrieved through the
FdoRdbmsOvPhysicalSchemaMapping class.
Brent.
-----Original Message-----
From: Haris Kurtagic [mailto:haris at sl-king.com]
Sent: Wednesday, October 25, 2006 12:57 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] fdo 3.2
Hi Orest,
1. I agree that most provider would support it differently
I suppose query of data based on rectangle of interest would be one of
the most common thing provider would do.
2. So allowing different character set could and up in different class
name's eventually.
I am using Physical/logical mapping inside provider.
I would appreciate if you can help me: I don't understand how to use
FdoPhysicalSchemaMapping
<https://fdo.osgeo.org/nonav/docs/FDO_API/d7/d94/class_fdo_physical_sche
ma_mapping.html> outside provider or rather to say it, use it without
knowing specific provider class sub implementation.
I see in interface functions like GetName or GetQualifiedName but don't
see how to get logical name and physical mapping for it.
Haris
________________________________
From: Orest Halustchak [mailto:orest.halustchak at autodesk.com]
Sent: Wednesday, October 25, 2006 4:25 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] fdo 3.2
Hi Haris,
Comments below ...
Thanks,
Orest.
________________________________
From: Haris Kurtagic [mailto:haris at sl-king.com]
Sent: Wednesday, October 25, 2006 6:53 AM
To: dev at fdo.osgeo.org
Subject: [fdo-dev] fdo 3.2
I've read FDO 3.2 changes, and it looks like good changes.
One of things if I understood correctly is that we will be able to use
any characters in schema.
[Orest] The provider can specify which characters are not allowed in a
name. But, if one provider decides to support a character that is not
supported by other providers, you may have problems applying schema used
in one provider against another provider unless you handle some sort of
name mangling.
I have couple of comments:
1. I saw changes in defining more exactly geometry type - good.
I miss very much rectangle or optimized rectangle especially in queries.
Now in filter provider gets polygon for some actions in MG, but
basically it is rectangle and
for some providers like for Oracle is important to know if it is
rectangle or really polygon.
Of course, provider can figure it out from points but it is no way it
should be.
[Orest] The FGF polygon in this case is derived from the OGC simple
feature spec which I don't believe has an explicit optimized rectangle
representation such as in Oracle. While this is something Oracle
supports, other targets may not have such capabilities. It is something
that possibly could be added to the FGF spec, but we would then need to
add a capability for providers to indicate that they don't handle that
polygon representation.
2. After coping fdo class from one provider to another, trough
AplySchema, it is difficult to get class definitions from newly created
classes.
Geometry/Class/schema name can be changed from one provider to
another.
It would be nice to have reader (like for insert geometries) which
would return map original class-new class, so the procedure is not
dependent on keeping same names.
[Orest] Fdo does not expect that the class name would be changed by the
provider. That is, if you define a particular class name with apply
schema, a subsequent describe schema would return the same class name. A
provider may limit the allowable class names via length limits and valid
characters. Note that class names in FDO are logical schema concepts as
opposed to physical schema concepts such as table names. Providers that
can support a logical / physical mapping will map class names to table
names where a class name may not be identical to the physical table
name.
Haris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo_dev/attachments/20061026/c6298d08/attachment.html
More information about the Fdo_dev
mailing list