Hi Orest,<br><br>comments in line<br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 12:20 AM, Orest Halustchak <span dir="ltr">&lt;<a href="mailto:orest.halustchak@autodesk.com">orest.halustchak@autodesk.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Haris,<br>
<br>
Yes, datastore is identified at the connection. So, I probably shouldn&#39;t have used the term &quot;qualifier&quot; 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.<br>

<br>
&gt;From the FDO developers guide, datastore is defined this way: &quot;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.&quot;<br>

<br>
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 &quot;dbo&quot;, 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&#39;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&#39;s a bug.<br>

<br>
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 &#39;owner&#39;, &#39;user&#39;, and &#39;schema&#39; 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?<br>
</blockquote><div><br>can you elaborate on &quot;separate FDO datastores within an Oracle instance&quot;<br>
<br>
I&#39;m only familiar with a single oracle instance having (users/schemas/owners),<br>
are you referring to datastores via meta data?  <br><br>CityOfNewYork.LandBase from CityOfAlbany.LandBase would be seperate schema&#39;s<br>and the unqualified LandBase would only refer to the Default Schema ie the connected user?<br>
<br>z<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
Thanks,<br>
Orest.<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>] On Behalf Of Haris Kurtagic<br>

</div><div><div></div><div class="h5">Sent: Wednesday, October 28, 2009 4:20 PM<br>
To: &#39;FDO Internals Mail List&#39;<br>
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming Conventions<br>
<br>
Hi Orest,<br>
<br>
I maybe wrong, but would like to clarify it with you. Datastores are<br>
introduced basically with metadata tables describing fdo classes. So in that<br>
sense I understand that in one database we could have multiple datastores<br>
but trough metadata tables. With concept of what later called &quot;native&quot;<br>
database classes there are no datastores ? That is my observation and same<br>
time question to you.<br>
Similar, regarding SQL server eventually we don&#39;t have database as level,<br>
because database is defined in connection string, right ?<br>
<br>
<br>
I agree about separate fdo classes for tables with multiple geometries, it<br>
would be nicer to have one class with multiple geometries.<br>
But, I think some APIs and even FDO based applications are making assumption<br>
about that one geometry is &quot;main geometry&quot;.<br>
There is no way that provider could construct FDO class from such table, to<br>
know what is main geometry (without metadata).<br>
<br>
Haris<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>] On Behalf Of Orest Halustchak<br>
Sent: Wednesday, October 28, 2009 1:57 PM<br>
To: FDO Internals Mail List<br>
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard<br>
FDO Class Naming Conventions<br>
<br>
Hi,<br>
<br>
Note that there is another qualifier that should be taken into account in<br>
these discussions and that is the datastore name. There are really three<br>
levels of qualification: datastore name, schema name, class name. So, cases<br>
where it is suggested to use the file name as the schema name, if the file<br>
name is already used for the datastore name, it doesn&#39;t have to be used<br>
again for the schema name.<br>
<br>
An issue with rdbms is that some such as SQL Server include the three levels<br>
of database, schema, and table. Others such as Oracle do not. So in the<br>
Oracle case if we map the datastore name to the Oracle user/schema, then we<br>
should not also use Oracle user/schema for FDO schema.<br>
<br>
Consider this example.<br>
        FDO Datastore = CityOfNewYork<br>
                FDO Schema = LandBase<br>
                        Class = Parcel<br>
                        Class = Road<br>
                FDO Schema = Water<br>
                        Class = Pipe<br>
                        Class = Valve<br>
                FDO Schema = Gas<br>
                        Class = Pipe<br>
<br>
        FDO Datastore = CityOfAlbany<br>
                Same schemas and classes<br>
<br>
We don&#39;t want to mix up the parcels from CityOfNewYork with the parcles from<br>
CityOfAlbany, those should be in separate tables. Having the Oracle schema<br>
name as LandBase, Water, and Gas doesn&#39;t handle this.<br>
<br>
Also, about the ~ColumnName convention being used for geometry columns, note<br>
that FDO does allow more than one geometry column per class with one flagged<br>
as the main geometry. I wouldn&#39;t want to require that these have to be<br>
exposed as separate feature classes.<br>
<br>
Thanks,<br>
Orest.<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:fdo-internals-bounces@lists.osgeo.org">fdo-internals-bounces@lists.osgeo.org</a>] On Behalf Of Haris Kurtagic<br>
Sent: Wednesday, October 28, 2009 6:07 AM<br>
To: &#39;FDO Internals Mail List&#39;<br>
Subject: [fdo-internals] RE: [mapguide-internals] FDO RFC 43 - Standard FDO<br>
Class Naming Conventions<br>
<br>
there is another important case which is not covered in RFC.<br>
Same table name in multiple schemas. Also, how to not mess up when users<br>
logs using different credentials.<br>
<br>
One way to solve that could be to always use rdbms schema name as fdo schema<br>
name.<br>
<br>
I believe it is absolutely necessary that application using FDO to access<br>
rdbms can be sure exactly which table and column it is accessing.<br>
Because what FDO provider sees when connects to rdbms can change regarding<br>
which credentials are used to connect to rdbms. That menas that on same<br>
database it can see only one table, or two tables (same name) in two schemas<br>
or even one or more geometry columns in table.<br>
<br>
I am not keen on current naming in King.Oracle with this ~ sign, but I am<br>
very pleased that when using King.Oracle and FDO class trough it, I know<br>
every time exactly which Oracle schema, table and column I am hitting.<br>
<br>
<br>
<br>
<br>
Just when wanted to finish something else from RFC:<br>
&quot;Class names for databases are normally tablename, unless qualified which<br>
then has ~COLUMN_NAME appended. (if the are multiple geometries, FDO<br>
requires to know which one is the identifier)&quot;<br>
<br>
In King.Oracle ~COLUMN_NAME is appened to make sure resulting name would be<br>
unique. Which actuall oracle column is used is not parsed from name of class<br>
but it is kept inside provider. ~COLUMN_NAME could be anything.<br>
<br>
<br>
Haris<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a><br>
[mailto:<a href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a>] On Behalf Of Zac Spitzer<br>
Sent: Wednesday, October 28, 2009 9:45 AM<br>
To: FDO Internals Mail List; MapGuide Internals Mail List<br>
Subject: [mapguide-internals] FDO RFC 43 - Standard FDO Class Naming<br>
Conventions<br>
<br>
I have posted RFC 43 for review<br>
<br>
<a href="http://trac.osgeo.org/fdo/wiki/FDORfc43" target="_blank">http://trac.osgeo.org/fdo/wiki/FDORfc43</a><br>
<br>
--<br>
Zac Spitzer -<br>
<a href="http://zacster.blogspot.com" target="_blank">http://zacster.blogspot.com</a><br>
+61 405 847 168<br>
_______________________________________________<br>
mapguide-internals mailing list<br>
<a href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a><br>
<br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
<br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
_______________________________________________<br>
fdo-internals mailing list<br>
<a href="mailto:fdo-internals@lists.osgeo.org">fdo-internals@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-internals" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-internals</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Zac Spitzer -<br><a href="http://zacster.blogspot.com">http://zacster.blogspot.com</a><br>+61 405 847 168<br>