[fdo-internals] King Oracle Issue
Zac Spitzer
zac.spitzer at gmail.com
Tue Jun 16 22:23:40 EDT 2009
Wasn't the main reason for this approach tables with multiple geometry columns?
It's a real pain and makes FDO really inconsistant as an abstraction layer...
The FDO PostGIS provider does this in a nice transparent fashion
http://zacster.blogspot.com/2008/08/some-ponderings-on-fdo-schemas.html
z
On Tue, Jun 16, 2009 at 8:53 PM, Haris Kurtagic<haris at sl-king.com> wrote:
> Hi Tomas,
>
>
>
> Regarding names of FDO classes and their representation in underlying data
> store is something which could be pain but I don't see right solution (other
> then use of additional metadata to describe generated name for FDO class).
> It is not only problem of King.Oracle or rdbms providers but also files.
> There are some steps in King.Oracle that could create names of FDO classes
> which would more look like original, but no 100% solution.
>
>
>
> KingFdoClass is metadata table which works and we use it a lot. You need to
> add row to it after creating table in Oracle. Row in KingFdoClass metadata
> table will not be auto added with apply schema command.
>
>
>
> - Schema is cached because of performance reasons. Right now it is necessary
> because of extensive use of DescribeSchema command by current FDO clients. I
> would much more prefer that schema would not be cached but right now it
> would not be practical.
>
>
>
> - Perhaps we changed something. As far as I remember it was different
> schema.
>
>
>
> - I was thinking about auto-updating metadata table with apply schema. But
> there are few scenarios in which it would not be possible. Also trough our
> experience of use of provider in our projects we realized we don't need it.
>
>
>
> Haris
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas Knoell
> Sent: Monday, June 15, 2009 9:43 PM
> To: 'FDO Internals Mail List'
> Subject: RE: [fdo-internals] King Oracle Issue
>
>
>
> Hi Haris,
>
>
>
> I got by the describe schema issue I had with the King Oracle provider.
> Executing the describe schema command after applying the schema now works
> fine.
>
>
>
> One thing that is unpleasant is the fact that the describe-schema
> implementation in the provider returns class names for feature classes that
> do not match the original class name: the new name is a combination of data
> store, class and geometry property name, all concatenated by a hyphen (for
> example DB1~MYCLASS~GEOM). That means that the application needs a provider
> specific implementation where the original class name can be mapped to the
> one the King Oracle provider uses.
>
>
>
> The link you provided in a previous mail describes a possibility to define a
> new class name of an existing geometry table using a King Oracle meta data
> table and hence providing a workaround to the fact that feature class names
> are altered. I applied this to the feature classes I created with the
> apply-schema command but it did not work: rather than replacing the name
> (for example) DB1~MYCLASS~GEOM with NewClass, it actually returns two
> classes now: DB1~MYCLASS~GEOM and NewClass (for which no table actually
> exists). Since the site you point to mentions that this option is in a BETA
> release status, I assume that either this may not be supported yet or I had
> an incorrect expectation. Could you please comment on this.
>
>
>
> There are a couple of other issues with this meta data table:
>
>
>
> Ø I updated the meta data table from the application after successfully
> applying the schema. Unfortunately, to have those changes take effect, I
> have to close and re-open the connection. before executing the describe
> schema command. I believe this should not be necessary.
>
> Ø Your site states that non feature classes identified via the meta data
> table belong to a schema named KingFdoClass. This is currently not the case
> as those classes are listed as members of the schema KingOra. Will this
> change for the final release?
>
>
>
> In my last mail I asked whether or not you plan to automatically maintain
> the meta data table if a schema is applied. Can you please comment on this
> as well?
>
>
>
> Thanks
>
>
>
> Thomas
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas Knoell
> Sent: June-10-09 5:21 PM
> To: 'FDO Internals Mail List'
> Subject: RE: [fdo-internals] King Oracle Issue
>
>
>
> Hi Haris,
>
>
>
> Thanks for the provided link, that is helpful.
>
>
>
> I created the table, added the information to the connection string and
> executed the test. I noted that the ApplySchema command is not adding any
> specified non feature classes to that table. Since the link you provided
> indicates that this is in Beta release at this point, is your final version
> enhancing your ApplySchema command implementation to automatically update
> this table for non feature classes?
>
>
>
> Thanks
>
>
>
> Thomas
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
> Sent: June-10-09 5:01 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] King Oracle Issue
>
>
>
> For tables which are not in sdo_geom_metadata you need to add them using
> "KingFdoClass" table (http://www.sl-king.com/fdooracle/KingFdoClass.htm).
>
>
>
> One reason I can remember right now for not working, would be because FDO
> schema is cached. You would need to restart provider ( there is also
> non-standard FDO function in King.Oracle connection).
>
> Haris
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas Knoell
> Sent: Wednesday, June 10, 2009 10:13 PM
> To: 'FDO Internals Mail List'
> Subject: RE: [fdo-internals] King Oracle Issue
>
>
>
> Hi Haris,
>
>
>
> Here are the answers to your questions:
>
>
>
>>> How did you applied schema ? You mention feature and non-feature class ?
>
>
>
> I executed the apply schema command (see below) from the FDO application.
> The schema that is defined and then applied contains a FdoFeatureClass and
> FdoClass. The application has to work with data stores that contain tables
> with and without spatial information and must be able to maintain them. That
> is why the test schema contains both classes.
>
>
>
>>> You applied Autodesk schema , metadata tables?
>
>
>
> The original data store did not contain any tables. However, since you
> mentioned it here, I added the f_* tables and tried it again – same result.
>
>
>
>>> In King.Oracle for Oracle Table to become available as FDO class the
>>> table has to be in sdo_geom_metadata . You did that ?
>
>>> Of 'course Oracle user you are using to connect has to see those tables
>>> etc...
>
>
>
> Since the schema was applied with the FdoIApplySchema interface, this should
> have been taken care of automatically. I checked and the feature class table
> does show up in sdo_geom_metadata. Obviously, the non feature class does
> not. And the Oracle user the application is connecting to can see those
> tables. So, are you saying that if I connect to an Oracle data store that
> does have tables without spatial information, I would not be able to use the
> insert/delete/update commands to maintain them when working with the King
> Oracle provider?
>
>
>
> Thanks
>
>
>
> Thomas
>
>
>
>
>
> FdoPtr<FdoIApplySchema> apply_schema_cmd =
>
> (FdoIApplySchema*) fdo_connection->CreateCommand(
>
>
> FdoCommandType_ApplySchema);
>
> FdoPtr<FdoFeatureSchemaCollection> schemas =
>
>
> FdoFeatureSchemaCollection::Create(NULL);
>
> FdoPtr<FdoFeatureSchema> schema =
>
> FdoFeatureSchema::Create(L"TestSchema", L"Test Schema");
>
> FdoPtr<FdoClassCollection> classes = schema->GetClasses();
>
>
>
> printf(" -> Defining feature class fc \n");
>
>
>
> FdoPtr<FdoFeatureClass> fc_class = FdoFeatureClass::Create(L"fc",
> L"fc");
>
> fc_class->SetIsAbstract(false);
>
>
>
> FdoPropertyDefinitionCollection *data_property_definitions =
>
>
> fc_class->GetProperties();
>
> FdoDataPropertyDefinitionCollection *id_property_definitions =
>
>
> fc_class->GetIdentityProperties();
>
>
>
> FdoDataPropertyDefinition *data_property_definition =
>
> FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
>
> data_property_definition->SetDataType(FdoDataType_Int64);
>
> data_property_definition->SetNullable(false);
>
> data_property_definition->SetIsAutoGenerated(true);
>
> data_property_definitions->Add(data_property_definition);
>
> id_property_definitions->Add(data_property_definition);
>
> FDO_SAFE_RELEASE(data_property_definition);
>
>
>
> data_property_definition =
>
> FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
>
> data_property_definition->SetDataType(FdoDataType_Int32);
>
> data_property_definition->SetNullable(true);
>
> data_property_definition->SetIsAutoGenerated(false);
>
> data_property_definitions->Add(data_property_definition);
>
> FDO_SAFE_RELEASE(data_property_definition);
>
>
>
> FdoGeometricPropertyDefinition *geometric_property_definition =
>
>
> FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp");
>
> geometric_property_definition->SetGeometryTypes(
>
> FdoGeometricType_Point |
>
> FdoGeometricType_Curve |
>
> FdoGeometricType_Surface |
>
> FdoGeometricType_Solid
> );
>
> geometric_property_definition->SetHasElevation(true);
>
> data_property_definitions->Add(geometric_property_definition);
>
> fc_class->SetGeometryProperty(geometric_property_definition);
>
> FDO_SAFE_RELEASE(geometric_property_definition);
>
> FDO_SAFE_RELEASE(id_property_definitions);
>
> FDO_SAFE_RELEASE(data_property_definitions);
>
>
>
> fc_class->SetBaseClass(NULL);
>
> classes->Add(fc_class);
>
>
>
> printf(" -> Defining non feature class nfc \n");
>
>
>
> FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc", L"nfc");
>
> nfc_class->SetIsAbstract(false);
>
>
>
> data_property_definitions = nfc_class->GetProperties();
>
> id_property_definitions = nfc_class->GetIdentityProperties();
>
>
>
> data_property_definition =
>
> FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
>
> data_property_definition->SetDataType(FdoDataType_Int32);
>
> data_property_definition->SetNullable(false);
>
> data_property_definition->SetIsAutoGenerated(false);
>
> data_property_definitions->Add(data_property_definition);
>
> id_property_definitions->Add(data_property_definition);
>
> FDO_SAFE_RELEASE(data_property_definition);
>
>
>
> data_property_definition =
>
> FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
>
> data_property_definition->SetDataType(FdoDataType_Int32);
>
> data_property_definition->SetNullable(true);
>
> data_property_definition->SetIsAutoGenerated(false);
>
> data_property_definitions->Add(data_property_definition);
>
> FDO_SAFE_RELEASE(data_property_definition);
>
> FDO_SAFE_RELEASE(id_property_definitions);
>
> FDO_SAFE_RELEASE(data_property_definitions);
>
>
>
> nfc_class->SetBaseClass(NULL);
>
> classes->Add(nfc_class);
>
>
>
> schemas->Add(schema);
>
>
>
> printf(" -> Applying the schema \n");
>
> apply_schema_cmd->SetFeatureSchema(schema);
>
> apply_schema_cmd->Execute();
>
>
>
>
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
> Sent: June-10-09 3:28 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] King Oracle Issue
>
>
>
> How did you applied schema ? You mention feature and non-feature class ? You
> applied Autodesk schema , metadata tables?
>
>
>
> In King.Oracle for Oracle Table to become available as FDO class the table
> has to be in sdo_geom_metadata . You did that ?
>
> Of 'course Oracle user you are using to connect has to see those tables
> etc...
>
>
>
> Haris
>
>
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas Knoell
> Sent: Wednesday, June 10, 2009 8:42 PM
> To: fdo-internals at lists.osgeo.org
> Subject: [fdo-internals] King Oracle Issue
>
>
>
> Hi,
>
>
>
> I am working on a FDO based application that should use the King Oracle
> Provider to connect to a data source on an Oracle 11g instance. The
> application currently connects fine to an empty data store (the data store
> does not contain any tables) and successfully applies a test schema that
> consists of a feature and a non feature class. The problem arises in the
> following step where a describe schema request is executed. In this case,
> the result is one schema named KingOra and no classes. I expected the test
> schema and its corresponding classes being reported.
>
>
>
> The application has access to all the DLLs that come with FDO. The DLLs were
> created by compiling the projects from the trunk in release mode. Due to the
> fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open
> each solution and compile it separately as some of the projects referenced
> MFC files that are not available with the Express Edition. Those issues were
> corrected in the shadow and all builds succeeded.
>
>
>
> Besides the changes to eliminate MFC references, one additional change was
> required in the King Oracle provider project in that the references to
> Oracle 10 libs were replaced by the corresponding Oracle 11 ones.
>
>
>
> Using the command built.bat –c=release –a=install –o=c:\FdoHome on the FDO
> and ThirdParty directory, all DLLs were copied into the specified folder and
> hence made accessible to the FDO application.
>
>
>
> The providers.xml file was modified to include the following statement for
> the King Oracle Provider:
>
>
>
> <FeatureProvider>
>
> <Name>King.Oracle.3.5</Name>
>
> <DisplayName>King Provider for Oracle</DisplayName>
>
> <Description>Read/write access to spatial and attribute data in an
> Oracle Spatial.</Description>
>
> <IsManaged>False</IsManaged>
>
> <Version>3.5.0.0</Version>
>
> <FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
>
> <LibraryPath>.\KingOracleProvider.dll</LibraryPath>
>
> </FeatureProvider>
>
>
>
> I did perform some debugging on the code. When following the statement that
> retrieves the schema name (see code below), I noted that it does not hit the
> function that implements the retrieval of the schema name but ends up in the
> function FdoCollection::GetCount() (file
> FDO\Unmanaged\Inc\Common\Collection.h). However, following other requests
> like the apply schema execute or the describe schema execute call, the
> correct functions are hit and executed. I also did some dependency checks on
> some DLLs and executables and nothing missing was reported.
>
>
>
> I assume that this may be just a simple setup issue but after trying
> multiple things now, I reached a point where I am not sure what to try next.
> If someone has any suggestions I would appreciate the feedback. Also, if
> there are additional questions, please let me know.
>
>
>
> Thanks
>
>
>
> Thomas
>
>
>
>
>
>
>
> FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
>
> (FdoIDescribeSchema*) fdo_connection->CreateCommand(
>
>
> FdoCommandType_DescribeSchema);
>
> FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute();
>
> FdoInt32 schema_count = schema_collection->GetCount();
>
> if (schema_count == 0)
>
> printf(" -> No schemas found \n");
>
> else
>
> for (int s = 0; s < schema_count; s++) {
>
>
>
> FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
>
> FdoStringP curr_schema_name = curr_schema->GetName();
>
> printf(" -> Schema[%d]: %ls \n", s, (FdoString
> *)curr_schema_name);
>
> FdoPtr<FdoClassCollection> curr_schema_classes =
>
> curr_schema->GetClasses();
>
> FdoInt32 curr_schema_class_count =
> curr_schema_classes->GetCount();
>
> if (curr_schema_class_count == 0)
>
> printf(" -> No classes found for current schema \n");
>
> else
>
> for (int sc = 0; sc < curr_schema_class_count; sc++) {
>
>
>
> FdoPtr<FdoClassDefinition> curr_schema_class =
>
>
> curr_schema_classes->GetItem(sc);
>
> FdoStringP curr_schema_class_name =
> curr_schema_class->GetName();
>
> printf(" -> Class[%d]: %ls \n",
>
> sc,
>
> (FdoString *)curr_schema_class_name);
>
>
>
> } // for (int sc = 0; ...
>
>
>
> } // for (int s = 0; ...
>
>
>
>
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>
--
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
More information about the fdo-internals
mailing list