FDO RFC 43 - Standard FDO Class Naming Conventions
|
|
| 1 2 |
zspitzer
|
I have posted RFC 43 for review
http://trac.osgeo.org/fdo/wiki/FDORfc43 -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Jackie Ng
|
Naming standardisation is sorely needed. Currently in FDO Toolbox, I'm having to code provider-specific hacks because of this naming discrepancy. I shouldn't have to be doing this.
- Jackie
|
||||
Haris Kurtagic
|
I don't believe that we would be able to normally (without all providers
having metadata) achieve that same full qualified name for FDO class is kept across all providers. I assume that your problems are pretty much same as I had in Fdo2Fdo application, how to know which name will come back from provider after applying schema. Perhaps, providers could return additional info about names of newly created classes. Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Jackie Ng Sent: Wednesday, October 28, 2009 10:21 AM To: [hidden email] Subject: Re: [fdo-internals] FDO RFC 43 - Standard FDO Class Naming Conventions Naming standardisation is sorely needed. Currently in FDO Toolbox, I'm having to code provider-specific hacks because of this naming discrepancy. I shouldn't have to be doing this. - Jackie zspitzer wrote: > > I have posted RFC 43 for review > > http://trac.osgeo.org/fdo/wiki/FDORfc43 > > -- > Zac Spitzer - > http://zacster.blogspot.com > +61 405 847 168 > > _______________________________________________ > fdo-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-internals > > -- View this message in context: http://n2.nabble.com/FDO-RFC-43-Standard-FDO-Class-Naming-Conventions-tp3904 182p3904311.html Sent from the FDO Internals mailing list archive at Nabble.com. _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
In reply to this post
by zspitzer
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: [hidden email] [mailto:[hidden email]] 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Orest Halustchak
|
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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
inline
On Wed, Oct 28, 2009 at 11:56 PM, Orest Halustchak <[hidden email]> wrote: Hi, My understanding is that FDO has no concept of datastore, it starts with schema's datastore is defined at the FDO connection level, why squeeze three levels into a two tier structure? 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. but that is a problem already solved when you follow the other way other database access layers work???? based on the connection details, either by specifying a datastore, or not Pipe would only be accessible if it was the default for the user or the for specified datastore. There is a implied concept of the default schema? if there's no default and two schemas means there are no schema less tables to enumerate This is how databases normally work in my experience which is all I'm trying to suggest with this RFC. 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.
-- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
Hi Zac, FDO does have a concept of datastore. There are FDO commands to
create, destroy, and list datastores. A datastore is also what you open with
the connection command. It plays a role. My example is meant to show a case of
two separate FDO datastores that for an rdbms are managed by one rdbms server. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer inline
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
Hi, I’d also like to add a comment about something that Haris said
in a separate reply. Ø Perhaps,
providers could return additional info about names of newly created classes. I think that’s a good idea, maybe a way for ApplySchema to return
information about anything that was changed from the user’s input. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak Hi Zac, FDO does have a concept of datastore. There are FDO commands to
create, destroy, and list datastores. A datastore is also what you open with
the connection command. It plays a role. My example is meant to show a case of
two separate FDO datastores that for an rdbms are managed by one rdbms server. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer inline
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
In reply to this post
by Orest Halustchak
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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
In reply to this post
by Orest Halustchak
sounds like another RFC ?
On Thu, Oct 29, 2009 at 1:04 AM, Orest Halustchak <[hidden email]> wrote:
-- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
would introducing the concept of a default schema resolve the issue of multiple
tables having the same name in different schemas? ie GetDefaultSchema() Sorry about my confusion about the datastore stuff, my FDO experience is predominately from working with MapGuide which doesn't expose them. Datastores (databases/instances) also are potentially named differently, where as a schema tends to be more consistant. If we introduce datastores into FDO Class names I fear things will become even more inconsistent. It's easy enough to change the name of a schema, but renaming a database is a much bigger change. As I described in the Proposed Test case: "Expose the Sheboygan dataset via FDO matching the standard conventions" is all about achieving the goal of making FDO provider agnostic SQL server does present a challenge here with it's three levels, but it if it has schema shouldn't we present them as schema's? well no because then we will be oft returning dbo which is completely non portable. z On Thu, Oct 29, 2009 at 12:21 PM, Zac Spitzer <[hidden email]> wrote: sounds like another RFC ? -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
In reply to this post
by Haris Kurtagic
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? Thanks, Orest. -----Original Message----- From: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/mapguide-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
In reply to this post
by zspitzer
Some javascript/style in this post has been disabled (why?)
Hi Zack, See my earlier email responding to Haris’ email. I didn’t
mean to suggest that we introduce datastore name to FDO class names. I probably
should have said ‘grouping mechanism’ rather than ‘qualifier’. What would default schema mean? Is that the schema that a
provider would create by default when you create a new datastore? For SQL Server, ‘dbo’ is the name that SQL Server
uses by default, but you can use other names such as ‘LandBase’. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer would introducing the concept
of a default schema resolve the issue of multiple On Thu, Oct 29, 2009 at 12:21 PM, Zac Spitzer <[hidden email]> wrote: sounds like another RFC ? On Thu, Oct 29, 2009 at 1:04 AM, Orest Halustchak <[hidden email]>
wrote: Hi, I’d also like to add a comment
about something that Haris said in a separate reply. Ø Perhaps, providers could return
additional info about names of newly created classes. I think that’s a good idea, maybe
a way for ApplySchema to return information about anything that was changed
from the user’s input. Thanks, Orest. From: [hidden email]
[mailto:[hidden email]]
On Behalf Of Orest Halustchak
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC
43 - Standard FDO Class Naming Conventions Hi Zac, FDO does have a concept of datastore.
There are FDO commands to create, destroy, and list datastores. A datastore is
also what you open with the connection command. It plays a role. My example is
meant to show a case of two separate FDO datastores that for an rdbms are
managed by one rdbms server. Thanks, Orest. From: [hidden email]
[mailto:[hidden email]]
On Behalf Of Zac Spitzer inline
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
In reply to this post
by zspitzer
Some javascript/style in this post has been disabled (why?)
Hi Zac, Yes, something like this would have to be a separate RFC. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer sounds like another RFC ? On Thu, Oct 29, 2009 at 1:04 AM, Orest Halustchak <[hidden email]>
wrote: Hi, I’d also like to add a comment about
something that Haris said in a separate reply. Ø Perhaps, providers could return
additional info about names of newly created classes. I think that’s a good idea, maybe a way
for ApplySchema to return information about anything that was changed from the
user’s input. Thanks, Orest. From: [hidden email]
[mailto:[hidden email]]
On Behalf Of Orest Halustchak
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC
43 - Standard FDO Class Naming Conventions Hi Zac, FDO does have a concept of datastore.
There are FDO commands to create, destroy, and list datastores. A datastore is
also what you open with the connection command. It plays a role. My example is
meant to show a case of two separate FDO datastores that for an rdbms are
managed by one rdbms server. Thanks, Orest. From: [hidden email]
[mailto:[hidden email]]
On Behalf Of Zac Spitzer inline
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Brent Robinson
|
In reply to this post
by zspitzer
Some javascript/style in this post has been disabled (why?)
Hi Zac, I had a look at RFC 43 and had a few questions regarding the
MySQL provider: 1. Do
the naming conventions apply only to MySQL databases that do not have FDO
MetaData? 2. For
the statement: “MySql? returns
schema:tablename or if connected as "schema" then just tablename” Is “schema”
equivalent to a MySQL database? 3. For
the case where the tables are exposed as in an empty schema, would that mean
that the DescribeSchema command would return a Feature Schema with blank name?
Or would there be a special name to represent the empty schema (e.g. “default”
or “none”). 4. What
sort of problems are you currently encountering without these naming conventions
being in place? a. Problems
copying schemas and features between providers? b. Problems
generating statements for the ISQLCommand? and a general question: are the conventions intended as
standards for all DBMS or file base providers or just the ones mentioned in the
RFC? If the answer to question 2 is yes then the MySQL provider is
currently close. The feature schema name is: FDO<database_name> FDO is prepended to the database name to handle a particular use
case which, in hindsight, is not likely very common (I’ll describe the
use case details later). This prefix could therefore be dropped from the feature
schema name. Exposing tables in the current database in an empty schema
sounds reasonable conceptually. Some users might not necessarily separate each
logical schema into a different MySQL database; a database might simply have a
collection of tables not tied to a particular schema. I have a few
implementation concerns but I’ll wait for the answer to question 3. Switching to the SQLServerSpatial provider, when the database
has no FDO Metadata, each SQL Server schema is presented as an FDO Feature
Schema. No special handling is done for the dbo schema. I was curious as to why
the dbo schema would be non-portable. It would be an unusual name for a logical
schema but could be copied to a provider, such as SDF, without having to rename
it. Getting back to the user case mentioned above, it would be the
case where the schema is copied from a MySQL database without FDO MetaData to a
database with Metadata, where the two databases have the same name but are in
different servers. The FDO-enabled databases have a special feature schema
(with same name as the database) which stores the datastore descriptions. This
schema is not directly modifiable so the copy would fail if the feature schema
being copied is named after the source database. To handle this, the FDO prefix
was added to the schema name. However, as mentioned above, this use case is not
likely very common. Brent. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer would introducing the concept
of a default schema resolve the issue of multiple On Thu, Oct 29, 2009 at 12:21 PM, Zac Spitzer <[hidden email]> wrote: sounds like another RFC ? On Thu, Oct 29, 2009 at 1:04 AM, Orest Halustchak <[hidden email]>
wrote: Hi, I’d also like to add a comment
about something that Haris said in a separate reply. Ø Perhaps, providers could return
additional info about names of newly created classes. I think that’s a good idea, maybe
a way for ApplySchema to return information about anything that was changed
from the user’s input. Thanks, Orest. From: [hidden email]
[mailto:[hidden email]]
On Behalf Of Orest Halustchak
Subject: RE: [fdo-internals] RE: [mapguide-internals] FDO RFC
43 - Standard FDO Class Naming Conventions Hi Zac, FDO does have a concept of datastore.
There are FDO commands to create, destroy, and list datastores. A datastore is
also what you open with the connection command. It plays a role. My example is
meant to show a case of two separate FDO datastores that for an rdbms are
managed by one rdbms server. Thanks, Orest. From: [hidden email]
[mailto:[hidden email]]
On Behalf Of Zac Spitzer inline
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
In reply to this post
by Orest Halustchak
Hi Orest,
comments in line On Fri, Oct 30, 2009 at 12:20 AM, Orest Halustchak <[hidden email]> wrote: Hi Haris, 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
-- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
In reply to this post
by Brent Robinson
On Fri, Oct 30, 2009 at 1:10 AM, Brent Robinson <[hidden email]> wrote:
FDO meta data describes a secondary set, I would assume the underlying tables would be always exposed in the same fashion..
That was my intention, I rarely use MySQL myself.. similiar to the oracle n sql server discussions
thats a really good question! We would want it describable if it's accessible, blank doesn't seem quite right, but it does imply the default or none or current... the unqualified name is a synonym for current_user.table_name
As jackie mentioned at the top to the thread, the same data loaded under a different provider appears different and thus cannot be just accessed without provider specific knowledge and coding workarounds
yes
yes
It is intended as a standard for all providers, I have updated the RFC to reflect that
dbo implies the unqualified schema naming and is meaningless out side sql server.. ie a database called dbo on mysql or an oracle user called dbo challenging problem
If you are using meta data, maybe turning it around and exposing metadata under FDO, also not very pretty
-- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
In reply to this post
by zspitzer
Some javascript/style in this post has been disabled (why?)
Hi Zac, Regarding separate FDO datastores within an Oracle instance, I’m
saying that a way to model that in Oracle is to create a new Oracle user for
each FDO datastore and then all the tables that I create for the classes within
that FDO datastore are all owned by the same Oracle user. So, all the tables
representing classes of a single FDO datastore are together. In your RFC, you said correctly that “…an
RDBMS schema might be composed of multiple logical schemas”
where for Oracle, the “RDBMS schema” (same as Oracle user/owner)
called CityOfNewYork contains multiple logical FDO schemas of LandBase, Water,
and Gas. In this case, there is no need for metadata to identify the FDO
datastore contents, but metadata would be used to identify FDO schemas. Now, if
I connect to a datastore in Oracle and there is no further information about FDO
schemas, then we can use a default schema name such as “Default”. I
think I’d rather use “Default” than having a blank name,
which is one of the options that you mentioned in your RFC and I wouldn’t
have a problem in standardizing on “Default”. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer Hi Orest, On Fri, Oct 30, 2009 at 12:20 AM, Orest Halustchak <[hidden email]>
wrote: Hi Haris,
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
Hi, Here is the proposal part of the RFC with my comments to show my
concerns. Proposed Solution ¶
[OH] Given that we deal with file and database providers,
if we want a general convention when a schema name is not available, I would
prefer to call it something like “Default”. For providers that
handle a directory of files, I guess I wouldn’t be too adverse to using
the directory name.
[OH] OK.
[OH] I would rather avoid empty schema names and use
something like “Default”.
[OH] I agree with class names for databases are normally derived
from table name (or view name), but I don’t want to require the
~COLUMN_NAME convention or require that a table with multiple geometries must
be mapped to multiple FDO classes. Providers may choose to do it that way or
providers may choose to map that to a single FDO class with multiple
geometries.
[OH] OK, unless overridden by custom mappings as per your
second bullet.
[OH] I prefer “Default:watercourses”. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak Hi Zac, Regarding separate FDO datastores within an Oracle instance,
I’m saying that a way to model that in Oracle is to create a new Oracle
user for each FDO datastore and then all the tables that I create for the
classes within that FDO datastore are all owned by the same Oracle user. So,
all the tables representing classes of a single FDO datastore are together. In your RFC, you said correctly that “…an
RDBMS schema might be composed of multiple logical schemas”
where for Oracle, the “RDBMS schema” (same as Oracle user/owner)
called CityOfNewYork contains multiple logical FDO schemas of LandBase, Water,
and Gas. In this case, there is no need for metadata to identify the FDO
datastore contents, but metadata would be used to identify FDO schemas. Now, if
I connect to a datastore in Oracle and there is no further information about
FDO schemas, then we can use a default schema name such as
“Default”. I think I’d rather use “Default” than
having a blank name, which is one of the options that you mentioned in your RFC
and I wouldn’t have a problem in standardizing on “Default”. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer Hi Orest, On Fri, Oct 30, 2009 at 12:20 AM, Orest Halustchak <[hidden email]>
wrote: Hi Haris,
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Brent Robinson
|
In reply to this post
by zspitzer
Some javascript/style in this post has been disabled (why?)
See inline, ([BR] heading). From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer On Fri, Oct 30, 2009 at 1:10 AM, Brent Robinson <[hidden email]>
wrote: Hi Zac, I had a look at RFC 43 and had a
few questions regarding the MySQL provider: 1. Do the naming conventions apply only to
MySQL databases that do not have FDO MetaData? FDO meta data describes a secondary set, I would assume the
underlying tables would be always [BR] – The metadata also describes the mappings between
tables and FDO Schemas and classes, so it would affect how the tables are
exposed. These mappings should continue to be supported if any users are taking
advantage of them.
That was my intention, I rarely use MySQL myself.. similiar
to the oracle n sql server discussions
thats a really good question! We would want it describable
if it's accessible, blank doesn't seem quite right, [BR] – Agreed. Having a special name for the empty schema
would be preferable to blank.
As jackie mentioned at the top to the thread, the same data
loaded under a different provider appears different
yes
yes
It is intended as a standard for all providers, I have
updated the RFC to reflect that [BR] – These are good for the more general providers but applying
as a standard for all providers might be too restrictive in some cases. At one
site I worked at in the past, all of the production data was in a single Oracle
user. Tables were grouped into schemas where table name was essentially: <schema_name>_<class_name> In this case, they would probably prefer to expose the
water_pipe and sewer_pipe tables as water:pipe and sewer:pipe, rather than default:water_pipe
and default:sewer_pipe. On the downside, this may expose them to the problems
that you and Jack encountered, but I still think they should have the latitude
to make these design trade-offs.
dbo implies the unqualified schema naming and is meaningless
out side sql server.. [BR] – At the SQL Server level, the default schema can be
set per-user. If connected as a user with “land” as the default
schema, then select * from parcel; would go against the land.parcel table, rather than dbo.parcel. If the unqualified schema naming at the FDO level is suppose to
mirror what happens at the user level, I’d be hesitant to introduce it
into the SQLServerSpatial provider since the corresponding FDO schema name for
a table could differ depending on which user connects.
[BR] –it is possible to create both. If a dbo schema is
copied to mysql or oracle, changing the name would be problematic . Since dbo
is not always the default schema, there would not be an obvious name to change
it to.
If you are using meta data, maybe turning it around and
exposing metadata under FDO, also not very pretty
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
