Changes between Version 25 and Version 26 of FDORfc33

Timestamp:

Apr 15, 2009, 12:35:07 PM (15 years ago)

Author:

gregboone

Comment:

--

FDORfc33

@@ -42 +42 @@
 To adjust for the these scenarios, providers should be modified to reverse engineer a class definition from the selected data and not attempt to match the select request to an existing FDO class. FDO Providers would be required to handle this in any case since an SQL 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. For example, Connect to data store called Denver and select from Boulder.Roads – the schema may or may not be similar to Denver.Roads. Providers should manufacture a new class definition unless they could determine with certainty that the select is on a table that matches one of the already defined FDO classes.
 
-Therefore, in cases where the resulting columns come from an existing FDO feature table, a provider can return the class definition 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 feature reader 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.
+Therefore, in cases where the resulting columns come from an existing FDO feature table, a provider can return the class definition 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 a feature reader does not necessarily correspond exactly to an existing FDO class definition. Existing class definitions may contain 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.
 
-In the circumstance that a computed class is generated, the FDO class definition’s !IsComputed property would return true. In that manner, applications would be able to distinguish the different feature reader responses coming from the providers and tailor their implementations accordingly. In such a situation, some care will also need to be given to the name of the generated schema and classes. At this point there is no standards exist. It would be beneficial if as a result of this RFC, some uniform conventions could be adopted. 
+In the circumstance that a computed class is generated, the FDO class definition’s !IsComputed property will return true. In that manner, applications are able to distinguish the content of the feature reader responses coming from the providers and tailor their implementations accordingly. In such a situation, some care will also need to be given to the name of the generated schema and classes. At this point there is no standards exist. It would be beneficial if as a result of this RFC, some uniform conventions could be adopted. 
 
 So following up on the above discussion providers, that do return feature readers from SQL commands, will need to come up with the appropriate class definition that the feature reader could expose.