Changes between Version 22 and Version 23 of FDORfc33

Timestamp:

Apr 15, 2009, 12:22:17 PM (15 years ago)

Author:

gregboone

Comment:

--

FDORfc33

@@ -31 +31 @@
 To a certain degree, the FDO feature reader assumes an FDO class definition is directly related to the properties being returned. With physical schema SQL (let’s say just Select command), there isn’t necessarily any FDO class definition that applies. This is why currently the SQL command's Execute method returns a data reader, which handles any generically returned data. Note that the FDO select aggregates command doesn’t return a feature reader either, since it’s returning computed data.
 
-We can break down the SQL pass through selects into a couple of categories. One category would be selecting data that really isn’t related to any of the FDO schema classes, e.g. selecting from system tables or views. For example: select from Oracle’s mdsys.cs_srs table, select from dual or SQL Server’s sys.indexes, etc. Even if we consider cases where the select is from a table that contains feature or feature related data, FDO does not provide a mechanism for returning some form of a class representation that identifies that feature data and makes operating on that data consistently with other feature data. 
+We can break down the SQL pass through selects into a couple of categories. One category would be selecting data that really isn’t related to any of the FDO schema classes, e.g. selecting from system tables or views. 
+
+    - Select from Oracle’s mdsys.cs_srs table. 
+    - Select from dual. 
+    - Select from SQL Server’s sys.indexes
+
+Even if we consider cases where the select is from a table that contains feature or feature related data, FDO does not provide a mechanism for returning some form of a class representation that identifies that feature data and makes operating on that data consistently with other feature data. 
 
 One suggestion has been to reverse engineer the select results and attempt to find the FDO class definition (coming from a describe schema request) that matches it. Other suggestions have been to construct a class definition on the fly, one that would not result from a call to describe schema. If the select is from a single table, providers could find the class definition that is based on that table and use it. However, then matching up the columns being selected with the properties in the logical schema, there may be some slight differences. This would result in the mixing of physical schema and logical schema elements together. For example, class names that are not the same as table names, property names that are not the same as column names, the use of additional computed columns, inclusion of pkey columns, etc. Granted that in many cases, the logical and physical views would be virtually identical. However, since that cannot be guaranteed, the design that is adopted will have to be able to handle the general case.