Changes between Version 17 and Version 18 of FDORfc33

Timestamp:

Apr 14, 2009, 7:39:54 AM (15 years ago)

Author:

gregboone

Comment:

--

FDORfc33

@@ -25 +25 @@
 Enable the FDO API to support SQL pass-through commands that return an FDO feature reader, referencing a proper FDO schema, not simply an FDO data reader. The feature reader will contain proper geometry properties, relations and associations. 
 
+TODO:
+
+-- Discuss code that used FR can use data coming back from Select or SQL !PassThrough. Cover more application cases.
+
 == Overview ==
 
@@ -35 +39 @@
 Even if we consider cases where the select is from a table that contains feature or feature related data, what does it mean to return a class definition for that data? Do we reverse engineer the select results and try to find the FDO class definition that seems to match it, that is one of the class definitions that you would get back from FDO’s describe schema? Do we just make up a class definition that may not even exist in FDO’s Describe Schema? If the select is from a single table, we possibly could find the class definition that is based on that table and use it. However, then we have to match up the columns being selected with properties in the logical schema, which may be slightly different – then we’re mixing physical schema and logical schema together (e.g. class names may not be the same as table names, property names may not be the same as column names, there may be additional computed columns, the user may not have selected the pkey columns – should we add them automatically?, etc.). Granted that in many cases, these would be virtually identical, but we can’t guarantee it and have to be able to handle the general case. Maybe we just reverse engineer a class definition from the selected data and not try to match up any existing FDO class? We would have to handle this anyway since a select may not match up at all with an existing class, such as selecting from a table with an owner that is different from the connected data store (e.g. connect to data store called Denver and select from Boulder.Roads – the schema may or may not be similar to Denver.Roads. Even worse, what happens if the user turns around and tries to update one of the returned objects – they’d have to get back to Boulder.Roads and not just try to update the FDO Roads feature class. So, this would have to be a different feature class.) It sounds like we’d manufacture a new class definition unless we could determine with certainty that the select is on a table that matches one of the already defined fdo classes. (An interesting case is “select r.* from roads r where r.length > 50”.)
 
+TODO:
+
+-- Reword away from questions. 
+
 Therefore, in cases where the resulting columns come from an existing FDO feature table, a provider can return the !FdoClassDefinition corresponding to that table. In cases where the columns come from an unknown table, a class definition can be constructed on the fly. By definition, the FDO class definition returned by an FdoIFeatureReader does not necessarily correspond exactly to an existing FDO class even in existing providers. This is due to the fact that it may only contains the properties that were asked for in the Select command, plus additional computed properties. It is perfectly legal to return a constructed class definition, which is only valid for the select that was executed, and not usable for further updates or inserts.
+
+TODO:
+
+-- Add !IsComputed reference
+-- Discuss schema/class name generation
 
 So following up on the above discussion, providers that return feature readers from SQLCommands will need to come up with the appropriate class definition that the feature reader could expose. 
@@ -46 +59 @@
     - Select is against a table that has an existing class definition, but the select is an aggregation that doesn’t return actual objects (e.g. select count(*), max(length) from roads). In this case it doesn’t make sense for the provider to return the same class name as for the underlying table since it is not actually returning road objects at all. This is basically another temporary class definition.
 
+TODO: 
+
+-- Figure out how providers can determine what are input/output paramaters
+-- Procedure calls, input/output parameters, etc....
+-- Examples
 
 == Requirements ==
@@ -117 +135 @@
 The question concerning which providers will need to be modified to support the SQL pass through enhancement is an open one and will depend on available development resources: I am assuming the following list:
 
+TODO: 
+
+-- Rework
+
     - SQLite
     - SQL Server Spatial