Is there a Feature class naming convention
|
|
Bruno Scott
|
When we create a feature class, let say using the MySQL provider we give a feature class name example: "MyFeatureClass"
and when we query it we use the same "MyFeatureClass" This is fine... With the PostGIS provider, we create the feature with a name like "MyFeatureClass" but we query with a different name example "MySchema.MyFeatureClass" We have this same problem with the King.Oracle provider When you have an application that uses any FDO RDBMS provider, it makes things very difficult to handle. We need to hardcode "if provider == PostGis" then "if provider == KingOracle then ... And it is a bit against the FDO philosophy, a single language to address the same way any spatial database,file It there a reason for that different naming? Bruno Scott |
||||||||||||||||
Orest Halustchak
|
I'm not sure why these providers would change the class names this way.
From FDO you can ask for class name and fully qualified class name separately so there should be no need to change the class name this way. Class name should come back as "MyFeatureClass" and fully qualified class name should come back as "MySchema:MyFeatureClass". Thanks, Orest. ------Original Message------ From: Bruno Scott To: [hidden email] ReplyTo: FDO Users Mail List Sent: Jan 22, 2008 10:33 AM Subject: [fdo-users] Is there a Feature class naming convention When we create a feature class, let say using the MySQL provider we give a feature class name example: "MyFeatureClass" and when we query it we use the same "MyFeatureClass" This is fine... With the PostGIS provider, we create the feature with a name like "MyFeatureClass" but we query with a different name example "MySchema.MyFeatureClass" We have this same problem with the King.Oracle provider When you have an application that uses any FDO RDBMS provider, it makes things very difficult to handle. We need to hardcode "if provider == PostGis" then "if provider == KingOracle then ... And it is a bit against the FDO philosophy, a single language to address the same way any spatial database,file It there a reason for that different naming? Bruno Scott -- View this message in context: http://www.nabble.com/Is-there-a-Feature-class-naming-convention-tp15021175s18162p15021175.html Sent from the fdo-users mailing list archive at Nabble.com. _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users -------------------------- Sent from my BlackBerry Wireless Handheld _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
|
Bruno Scott
|
When i query the className against the OGR PostGIS
it returns : MySchema~MyTable When i query the className against the King.Oracle it returns : MySchema~MyTable~myGeometryColumn So if classname should be "MyTable" and fully qualified name "MySchema:MyTable" Can we consider this as a bug in these 2 providers?
|
||||
Traian Stanev
|
>From what I vaguely remember (and I wrote that code in the OGR provider), some OGRLayers (which correspond to FDO feature classes in the OGR provider) came back with a . in the name. Basically the OGR Layer name was of the form "TABLE.CLASS" or something like that, and that whole string corresponds to one feature class. Since "." was not a valid character for FDO, I replaced it by ~ in such cases. Note that all of these feature classes are expressed as belonging to a single OGR connection schema called OGRSchema. So you can access the feature class "TABLE.LAYER" using: OGRSchema:TABLE~LAYER The OGR provider takes care of this transparently when going back to the database and will convert that back to TABLE.LAYER. As long as you are using the FDO API to do all this, it will work fine and complies with the FDO naming conventions. The class name is not ambiguous and the provider knows exactly what to do as long as you use that class name. What you are really questioning here is that the feature class name as reported by the FDO provider does not match the native table name in the database. Why is this a bug? Traian > -----Original Message----- > From: [hidden email] [mailto:fdo-users- > [hidden email]] On Behalf Of Bruno Scott > Sent: Tuesday, January 22, 2008 11:55 AM > To: [hidden email] > Subject: Re: [fdo-users] Is there a Feature class naming convention > > > When i query the className against the OGR PostGIS > it returns : MySchema~MyTable > > When i query the className against the King.Oracle > it returns : MySchema~MyTable~myGeometryColumn > > So if classname should be "MyTable" and fully qualified name > "MySchema:MyTable" > Can we consider this as a bug in these 2 providers? > > > > > Orest Halustchak wrote: > > > > I'm not sure why these providers would change the class names this > way. > > > > From FDO you can ask for class name and fully qualified class name > > separately so there should be no need to change the class name this > way. > > Class name should come back as "MyFeatureClass" and fully qualified > class > > name should come back as "MySchema:MyFeatureClass". > > > > Thanks, > > Orest. > > > > ------Original Message------ > > From: Bruno Scott > > To: [hidden email] > > ReplyTo: FDO Users Mail List > > Sent: Jan 22, 2008 10:33 AM > > Subject: [fdo-users] Is there a Feature class naming convention > > > > > > When we create a feature class, let say using the MySQL provider we > give a > > feature class name example: "MyFeatureClass" > > and when we query it we use the same "MyFeatureClass" > > This is fine... > > > > With the PostGIS provider, we create the feature with a name like > > "MyFeatureClass" > > but we query with a different name example "MySchema.MyFeatureClass" > > > > We have this same problem with the King.Oracle provider > > > > When you have an application that uses any FDO RDBMS provider, it > makes > > things very difficult to handle. > > We need to hardcode > > "if provider == PostGis" then > > "if provider == KingOracle then > > ... > > > > And it is a bit against the FDO philosophy, a single language to > address > > the > > same way any spatial database,file > > > > > > It there a reason for that different naming? > > > > Bruno Scott > > > > > > > > > > -- > > View this message in context: > > http://www.nabble.com/Is-there-a-Feature-class-naming-convention- > tp15021175s18162p15021175.html > > Sent from the fdo-users mailing list archive at Nabble.com. > > > > _______________________________________________ > > fdo-users mailing list > > [hidden email] > > http://lists.osgeo.org/mailman/listinfo/fdo-users > > > > > > -------------------------- > > Sent from my BlackBerry Wireless Handheld > > > > _______________________________________________ > > fdo-users mailing list > > [hidden email] > > http://lists.osgeo.org/mailman/listinfo/fdo-users > > > > > > -- > View this message in context: http://www.nabble.com/Is-there-a-Feature- > class-naming-convention-tp15021175s18162p15023058.html > Sent from the fdo-users mailing list archive at Nabble.com. > > _______________________________________________ > fdo-users mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-users fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
|
Orest Halustchak
|
There are two scenarios.
If the provider is accessing an existing schema, e.g. not created by fdo, then the provider decides how to map the table / file to a class and schema. The main thing is that the mapping is unique and unambiguous as Traian said. The other scenario is if a new class is defined via fdo. In this case, the caller is specifying an explicit schema name and class name. A describe of that class then should come back with the same names as long as the input names were valid (FdoISchemaCapabilities has methods to get information about valid names such as name size limits and valid characters). Thanks, Orest. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Traian Stanev Sent: Tuesday, January 22, 2008 12:11 PM To: [hidden email] Subject: RE: [fdo-users] Is there a Feature class naming convention >From what I vaguely remember (and I wrote that code in the OGR provider), some OGRLayers (which correspond to FDO feature classes in the OGR provider) came back with a . in the name. Basically the OGR Layer name was of the form "TABLE.CLASS" or something like that, and that whole string corresponds to one feature class. Since "." was not a valid character for FDO, I replaced it by ~ in such cases. Note that all of these feature classes are expressed as belonging to a single OGR connection schema called OGRSchema. So you can access the feature class "TABLE.LAYER" using: OGRSchema:TABLE~LAYER The OGR provider takes care of this transparently when going back to the database and will convert that back to TABLE.LAYER. As long as you are using the FDO API to do all this, it will work fine and complies with the FDO naming conventions. The class name is not ambiguous and the provider knows exactly what to do as long as you use that class name. What you are really questioning here is that the feature class name as reported by the FDO provider does not match the native table name in the database. Why is this a bug? Traian > -----Original Message----- > From: [hidden email] [mailto:fdo-users- > [hidden email]] On Behalf Of Bruno Scott > Sent: Tuesday, January 22, 2008 11:55 AM > To: [hidden email] > Subject: Re: [fdo-users] Is there a Feature class naming convention > > > When i query the className against the OGR PostGIS > it returns : MySchema~MyTable > > When i query the className against the King.Oracle > it returns : MySchema~MyTable~myGeometryColumn > > So if classname should be "MyTable" and fully qualified name > "MySchema:MyTable" > Can we consider this as a bug in these 2 providers? > > > > > Orest Halustchak wrote: > > > > I'm not sure why these providers would change the class names this > way. > > > > From FDO you can ask for class name and fully qualified class name > > separately so there should be no need to change the class name this > way. > > Class name should come back as "MyFeatureClass" and fully qualified > class > > name should come back as "MySchema:MyFeatureClass". > > > > Thanks, > > Orest. > > > > ------Original Message------ > > From: Bruno Scott > > To: [hidden email] > > ReplyTo: FDO Users Mail List > > Sent: Jan 22, 2008 10:33 AM > > Subject: [fdo-users] Is there a Feature class naming convention > > > > > > When we create a feature class, let say using the MySQL provider we > give a > > feature class name example: "MyFeatureClass" > > and when we query it we use the same "MyFeatureClass" > > This is fine... > > > > With the PostGIS provider, we create the feature with a name like > > "MyFeatureClass" > > but we query with a different name example "MySchema.MyFeatureClass" > > > > We have this same problem with the King.Oracle provider > > > > When you have an application that uses any FDO RDBMS provider, it > makes > > things very difficult to handle. > > We need to hardcode > > "if provider == PostGis" then > > "if provider == KingOracle then > > ... > > > > And it is a bit against the FDO philosophy, a single language to > address > > the > > same way any spatial database,file > > > > > > It there a reason for that different naming? > > > > Bruno Scott > > > > > > > > > > -- > > View this message in context: > > http://www.nabble.com/Is-there-a-Feature-class-naming-convention- > tp15021175s18162p15021175.html > > Sent from the fdo-users mailing list archive at Nabble.com. > > > > _______________________________________________ > > fdo-users mailing list > > [hidden email] > > http://lists.osgeo.org/mailman/listinfo/fdo-users > > > > > > -------------------------- > > Sent from my BlackBerry Wireless Handheld > > > > _______________________________________________ > > fdo-users mailing list > > [hidden email] > > http://lists.osgeo.org/mailman/listinfo/fdo-users > > > > > > -- > View this message in context: http://www.nabble.com/Is-there-a-Feature- > class-naming-convention-tp15021175s18162p15023058.html > Sent from the fdo-users mailing list archive at Nabble.com. > > _______________________________________________ > fdo-users mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-users fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
|
Traian Stanev
|
Yes, if the provider can create tables, this would be a problem to fix.
The OGR provider can't do that, but I think the Kind provider can, so it may need fixing. Traian > -----Original Message----- > From: [hidden email] [mailto:fdo-users- > [hidden email]] On Behalf Of Orest Halustchak > Sent: Tuesday, January 22, 2008 12:35 PM > To: FDO Users Mail List > Subject: RE: [fdo-users] Is there a Feature class naming convention > > There are two scenarios. > > If the provider is accessing an existing schema, e.g. not created by > fdo, then the provider decides how to map the table / file to a class > and schema. The main thing is that the mapping is unique and > unambiguous as Traian said. > > The other scenario is if a new class is defined via fdo. In this case, > the caller is specifying an explicit schema name and class name. A > describe of that class then should come back with the same names as > long as the input names were valid (FdoISchemaCapabilities has methods > to get information about valid names such as name size limits and valid > characters). > > Thanks, > Orest. > > -----Original Message----- > From: [hidden email] [mailto:fdo-users- > [hidden email]] On Behalf Of Traian Stanev > Sent: Tuesday, January 22, 2008 12:11 PM > To: [hidden email] > Subject: RE: [fdo-users] Is there a Feature class naming convention > > > >From what I vaguely remember (and I wrote that code in the OGR > provider), some OGRLayers (which correspond to FDO feature classes in > the OGR provider) came back with a . in the name. Basically the OGR > Layer name was of the form "TABLE.CLASS" or something like that, and > that whole string corresponds to one feature class. Since "." was not a > valid character for FDO, I replaced it by ~ in such cases. > > Note that all of these feature classes are expressed as belonging to a > single OGR connection schema called OGRSchema. So you can access the > feature class "TABLE.LAYER" using: > > OGRSchema:TABLE~LAYER > > The OGR provider takes care of this transparently when going back to > the database and will convert that back to TABLE.LAYER. > > As long as you are using the FDO API to do all this, it will work fine > and complies with the FDO naming conventions. The class name is not > ambiguous and the provider knows exactly what to do as long as you use > that class name. > > > What you are really questioning here is that the feature class name as > reported by the FDO provider does not match the native table name in > the database. Why is this a bug? > > > Traian > > > > > > -----Original Message----- > > From: [hidden email] [mailto:fdo-users- > > [hidden email]] On Behalf Of Bruno Scott > > Sent: Tuesday, January 22, 2008 11:55 AM > > To: [hidden email] > > Subject: Re: [fdo-users] Is there a Feature class naming convention > > > > > > When i query the className against the OGR PostGIS > > it returns : MySchema~MyTable > > > > When i query the className against the King.Oracle > > it returns : MySchema~MyTable~myGeometryColumn > > > > So if classname should be "MyTable" and fully qualified name > > "MySchema:MyTable" > > Can we consider this as a bug in these 2 providers? > > > > > > > > > > Orest Halustchak wrote: > > > > > > I'm not sure why these providers would change the class names this > > way. > > > > > > From FDO you can ask for class name and fully qualified class name > > > separately so there should be no need to change the class name this > > way. > > > Class name should come back as "MyFeatureClass" and fully qualified > > class > > > name should come back as "MySchema:MyFeatureClass". > > > > > > Thanks, > > > Orest. > > > > > > ------Original Message------ > > > From: Bruno Scott > > > To: [hidden email] > > > ReplyTo: FDO Users Mail List > > > Sent: Jan 22, 2008 10:33 AM > > > Subject: [fdo-users] Is there a Feature class naming convention > > > > > > > > > When we create a feature class, let say using the MySQL provider we > > give a > > > feature class name example: "MyFeatureClass" > > > and when we query it we use the same "MyFeatureClass" > > > This is fine... > > > > > > With the PostGIS provider, we create the feature with a name like > > > "MyFeatureClass" > > > but we query with a different name example > "MySchema.MyFeatureClass" > > > > > > We have this same problem with the King.Oracle provider > > > > > > When you have an application that uses any FDO RDBMS provider, it > > makes > > > things very difficult to handle. > > > We need to hardcode > > > "if provider == PostGis" then > > > "if provider == KingOracle then > > > ... > > > > > > And it is a bit against the FDO philosophy, a single language to > > address > > > the > > > same way any spatial database,file > > > > > > > > > It there a reason for that different naming? > > > > > > Bruno Scott > > > > > > > > > > > > > > > -- > > > View this message in context: > > > http://www.nabble.com/Is-there-a-Feature-class-naming-convention- > > tp15021175s18162p15021175.html > > > Sent from the fdo-users mailing list archive at Nabble.com. > > > > > > _______________________________________________ > > > fdo-users mailing list > > > [hidden email] > > > http://lists.osgeo.org/mailman/listinfo/fdo-users > > > > > > > > > -------------------------- > > > Sent from my BlackBerry Wireless Handheld > > > > > > _______________________________________________ > > > fdo-users mailing list > > > [hidden email] > > > http://lists.osgeo.org/mailman/listinfo/fdo-users > > > > > > > > > > -- > > View this message in context: http://www.nabble.com/Is-there-a- > Feature- > > class-naming-convention-tp15021175s18162p15023058.html > > Sent from the fdo-users mailing list archive at Nabble.com. > > > > _______________________________________________ > > fdo-users mailing list > > [hidden email] > > http://lists.osgeo.org/mailman/listinfo/fdo-users > _______________________________________________ > fdo-users mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-users > _______________________________________________ > fdo-users mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-users fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
Jason Birch
|
In reply to this post
by Orest Halustchak
I believe that the PostGIS provider only implements the native PostGIS data access, and has no way of storing FDO-specific logical/physical mappings (not sure if I have the right terminology here). I believe that the second scenario would require the PostGIS provider to implement some way of persisting this information? Jason -----Original Message----- From: Orest Halustchak Subject: RE: [fdo-users] Is there a Feature class naming convention If the provider is accessing an existing schema, e.g. not created by fdo, then the provider decides how to map the table / file to a class and schema. The main thing is that the mapping is unique and unambiguous as Traian said. The other scenario is if a new class is defined via fdo. In this case, the caller is specifying an explicit schema name and class name. A describe of that class then should come back with the same names as long as the input names were valid (FdoISchemaCapabilities has methods to get information about valid names such as name size limits and valid characters). _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
|
Bruno Scott
|
Let me explain my problem.
We have developped a huge application that does lot of specific industry task. These industry are Transportation,Cadaster,Facility management,Telco and so on. We historically used 2 driver to access and Maintain all these data : OleDb and OCI We have recently added support to FDO The same application could run on Access,SqlServer,Oracle,MySql.... with the same setting (table name, column name...) only the connection string change. To make sure that everything works fine we do unit testing on each of these databases. Symmary of the steps involved in unit testing drop all the tables Create all the tables fill all the tables with known values Launch some specific industry fonction Test if the function did the right thing A specific industry function consist of one or many of these: Select some record Insert some record Delete some record Update some record The only things the application knows to acheive this are a connection string to the database a table name with optionnaly a schema name the column names This end up with something like this Drop table "MyTable"... Create table "MyTable"... Insert into "MyTable"... ... These sequence of statement work fine on Most fdo provider Autodesk.Oracle Autodesk.SqlServer Osgeo.MySQL Osgeo.SDF Osgeo.SHP I have problems with Osgeo.PostGIS, with PostGIS i have to do that to make it working Drop table "MyTable"... Create table "MyTable"... Insert into "MySchema~MyTable"... How i am suppose to know that the featureclass name should be "MySchema~MyTable" instead of "MyTable" I wish FDO had a method like GetPhysicalName who would return "MySchema.MyTable" So i would be able to map featureclassName to physical table name automatically Bruno
|
||||||||||||||||
|
Bruno Scott
|
Specifically for the PostGIS provider
we specify the connection string with Service : MyDatabase@host:port Datastore : MySchema So i think the featureclass name could only be "MyTable" instead of "MySchema~MyTable" Because we have already the datastore/Schema in the connection string Am i right? Bruno
|
||||||||||||||||
|
Traian Stanev
|
Yes. The only reason King and PostGIS have this problem is because some of their code was based on the OGR provider, not because of some convention. They don't really have to do the name translation since they can make assumptions about the underlying database. You can enter a Trac ticket for that, if you haven't done so already. Traian ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Bruno Scott [[hidden email]] Sent: Wednesday, January 23, 2008 8:50 AM To: [hidden email] Subject: RE: [fdo-users] Is there a Feature class naming convention Specifically for the PostGIS provider we specify the connection string with Service : MyDatabase@host:port Datastore : MySchema So i think the featureclass name could only be "MyTable" instead of "MySchema~MyTable" Because we have already the datastore/Schema in the connection string Am i right? Bruno Bruno Scott wrote: > > Let me explain my problem. > We have developped a huge application that does lot of specific industry > task. > These industry are Transportation,Cadaster,Facility management,Telco and > so on. > We historically used 2 driver to access and Maintain all these data : > OleDb and OCI > We have recently added support to FDO > The same application could run on Access,SqlServer,Oracle,MySql.... with > the same setting (table name, column name...) only the connection string > change. > To make sure that everything works fine we do unit testing on each of > these databases. > Symmary of the steps involved in unit testing > drop all the tables > Create all the tables > fill all the tables with known values > Launch some specific industry fonction > Test if the function did the right thing > A specific industry function consist of one or many of these: > Select some record > Insert some record > Delete some record > Update some record > > The only things the application knows to acheive this are > a connection string to the database > a table name with optionnaly a schema name > the column names > > This end up with something like this > Drop table "MyTable"... > Create table "MyTable"... > Insert into "MyTable"... > ... > > These sequence of statement work fine on Most fdo provider > Autodesk.Oracle > Autodesk.SqlServer > Osgeo.MySQL > Osgeo.SDF > Osgeo.SHP > I have problems with Osgeo.PostGIS, > with PostGIS i have to do that to make it working > Drop table "MyTable"... > Create table "MyTable"... > Insert into "MySchema~MyTable"... > > How i am suppose to know that the featureclass name should be > "MySchema~MyTable" instead of "MyTable" > I wish FDO had a method like GetPhysicalName who would return > "MySchema.MyTable" > So i would be able to map featureclassName to physical table name > automatically > > Bruno > > > > > JasonBirch wrote: >> >> >> I believe that the PostGIS provider only implements the native PostGIS >> data access, and has no way of storing FDO-specific logical/physical >> mappings (not sure if I have the right terminology here). I believe >> that the second scenario would require the PostGIS provider to implement >> some way of persisting this information? >> >> Jason >> >> -----Original Message----- >> From: Orest Halustchak >> Subject: RE: [fdo-users] Is there a Feature class naming convention >> >> If the provider is accessing an existing schema, e.g. not created by >> fdo, then the provider decides how to map the table / file to a class >> and schema. The main thing is that the mapping is unique and unambiguous >> as Traian said. >> >> The other scenario is if a new class is defined via fdo. In this case, >> the caller is specifying an explicit schema name and class name. A >> describe of that class then should come back with the same names as long >> as the input names were valid (FdoISchemaCapabilities has methods to get >> information about valid names such as name size limits and valid >> characters). >> >> _______________________________________________ >> fdo-users mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/fdo-users >> >> > > -- View this message in context: http://www.nabble.com/Is-there-a-Feature-class-naming-convention-tp15021175s18162p15042014.html Sent from the fdo-users mailing list archive at Nabble.com. _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
|
Orest Halustchak
|
In reply to this post
by Bruno Scott
Hi Bruno,
My view is that encoding the schema name as part of the class name is redundant. However, FDO does not have any "rules" regarding how to reverse engineer a table name into a class name when accessing an existing rdbms schema where there is no additional fdo logical/physical mapping metadata persisted. FDO does have a concept of physical schema overrides where you can specify or retrieve physical schema information such as table names and column names for classes and properties. However, being physical attributes, they are different for different providers - e.g. file providers have different physical attributes from database providers. Even different database types have different physical attributes. The Autodesk Oracle provider for example includes physical overrides that include table name and column name information such as table name, tablespace name, and owner. These are not exposed in the generic FDO api as they can be quite different for different physical sources. I had thought about a generic technique such as name/value pair list that could be exposed through a generic and still expose provider specific attributes, but we haven't gone down that path yet. It would need some discussion and design. (As an aside, have you seen the futures list on the fdo osgeo wiki, http://trac.osgeo.org/fdo/wiki/FdoFutures?) While mandating strict rules for table name to class name reverse engineering may be a simple solution, I'm not sure that it's the best way to go. Orest. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Bruno Scott Sent: Wednesday, January 23, 2008 8:51 AM To: [hidden email] Subject: RE: [fdo-users] Is there a Feature class naming convention Specifically for the PostGIS provider we specify the connection string with Service : MyDatabase@host:port Datastore : MySchema So i think the featureclass name could only be "MyTable" instead of "MySchema~MyTable" Because we have already the datastore/Schema in the connection string Am i right? Bruno Bruno Scott wrote: > > Let me explain my problem. > We have developped a huge application that does lot of specific industry > task. > These industry are Transportation,Cadaster,Facility management,Telco and > so on. > We historically used 2 driver to access and Maintain all these data : > OleDb and OCI > We have recently added support to FDO > The same application could run on Access,SqlServer,Oracle,MySql.... with > the same setting (table name, column name...) only the connection string > change. > To make sure that everything works fine we do unit testing on each of > these databases. > Symmary of the steps involved in unit testing > drop all the tables > Create all the tables > fill all the tables with known values > Launch some specific industry fonction > Test if the function did the right thing > A specific industry function consist of one or many of these: > Select some record > Insert some record > Delete some record > Update some record > > The only things the application knows to acheive this are > a connection string to the database > a table name with optionnaly a schema name > the column names > > This end up with something like this > Drop table "MyTable"... > Create table "MyTable"... > Insert into "MyTable"... > ... > > These sequence of statement work fine on Most fdo provider > Autodesk.Oracle > Autodesk.SqlServer > Osgeo.MySQL > Osgeo.SDF > Osgeo.SHP > I have problems with Osgeo.PostGIS, > with PostGIS i have to do that to make it working > Drop table "MyTable"... > Create table "MyTable"... > Insert into "MySchema~MyTable"... > > How i am suppose to know that the featureclass name should be > "MySchema~MyTable" instead of "MyTable" > I wish FDO had a method like GetPhysicalName who would return > "MySchema.MyTable" > So i would be able to map featureclassName to physical table name > automatically > > Bruno > > > > > JasonBirch wrote: >> >> >> I believe that the PostGIS provider only implements the native PostGIS >> data access, and has no way of storing FDO-specific logical/physical >> mappings (not sure if I have the right terminology here). I believe >> that the second scenario would require the PostGIS provider to implement >> some way of persisting this information? >> >> Jason >> >> -----Original Message----- >> From: Orest Halustchak >> Subject: RE: [fdo-users] Is there a Feature class naming convention >> >> If the provider is accessing an existing schema, e.g. not created by >> fdo, then the provider decides how to map the table / file to a class >> and schema. The main thing is that the mapping is unique and unambiguous >> as Traian said. >> >> The other scenario is if a new class is defined via fdo. In this case, >> the caller is specifying an explicit schema name and class name. A >> describe of that class then should come back with the same names as long >> as the input names were valid (FdoISchemaCapabilities has methods to get >> information about valid names such as name size limits and valid >> characters). >> >> _______________________________________________ >> fdo-users mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/fdo-users >> >> > > -- View this message in context: http://www.nabble.com/Is-there-a-Feature-class-naming-convention-tp15021175s18162p15042014.html Sent from the fdo-users mailing list archive at Nabble.com. _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
Chris Erickson
|
In reply to this post
by Bruno Scott
Some javascript/style in this post has been disabled (why?)
I’m running into this same naming anomaly on the King.MsSqlSpatial
provider. Does anybody know if it has been fixed there, or can be? Thanks, Chris Erickson _______________________________________________ fdo-users mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-users |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
