[fdo-internals] King Oracle Issue
Thomas Knoell
thomas.knoell at supernaanalytics.com
Mon Jun 15 15:43:00 EDT 2009
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; ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20090615/29a96bc3/attachment-0001.html
More information about the fdo-internals
mailing list