Changes between Version 25 and Version 26 of FDORfc50
- Timestamp:
- Jun 4, 2010, 6:23:12 AM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FDORfc50
v25 v26 43 43 * '''Cons''': We need to change all the providers leading to a big effort from everyone. 44 44 45 * Enhance FdoISelect, add two new methods ''!GetFeatureClassNames()'' and ''!GetJoinCriteria()'' with the default implementation of these methods throwing an exception. Providers which want to implement these new methods must override the nand provide a detailed implementation. Even though FdoISelect is declared as ''interface'' we do not have real interfaces in the FDO C++ API, and abstract methods can co-exist with those that have a default implementation. A good example here are the locking methods on the select command. Most providers do not support locking and have to provide an empty implementation (usually to throw an exception), creating more code on provider side. A better plan would have provided a default implementation in the FdoISelect base class. Following this idea, this alternative will just modify the FdoISelect base class, allowing providers that that will not support joins to remain unchanged. These providers will inherit the default implementation. Looking at FdoISelect there are already two methods which provide default implementation: !AddRef() and Release(), so adding default implementation for the new methods will not be something totally new. As with option 2 above: Two new capability functions will be added to the FDO FdoIConnectionCapabilities Interface so that applications can determine if a provider supports the join criteria and supported join types. These new capabilites would be named: !SupportsJoins() & !GetJoinTypes().45 * Enhance FdoISelect, add two new methods ''!GetFeatureClassNames()'' and ''!GetJoinCriteria()'' with the default implementation of these methods throwing an exception. Providers which want to implement these new methods must override them and provide a detailed implementation. Even though FdoISelect is declared as ''interface'' we do not have real interfaces in the FDO C++ API, and abstract methods can co-exist with those that have a default implementation. A good example here are the locking methods on the select command. Most providers do not support locking and have to provide an empty implementation (usually to throw an exception), creating more code on provider side. A better plan would have provided a default implementation in the FdoISelect base class. Following this idea, this alternative will just modify the FdoISelect base class, allowing providers that that will not support joins to remain unchanged. These providers will inherit the default implementation. Looking at FdoISelect there are already two methods which provide default implementation: !AddRef() and Release(), so adding default implementation for the new methods will not be something totally new. As with option 2 above: Two new capability functions will be added to the FDO FdoIConnectionCapabilities Interface so that applications can determine if a provider supports the join criteria and supported join types. These new capabilites would be named: !SupportsJoins() & !GetJoinTypes(). 46 46 * '''Pros''': this solution will not add more complexity to the API, we do not need to change any provider.[[BR]] 47 47 * '''Cons''': None. … … 86 86 We should be able to select from multiple classes and have filters applied on any class attributes. In order to be able to achieve that objective, we can use FdoISelect::!GetFeatureClassNames() and add all classes we want to select from. The filter must be based on properties from the selected classes and filter can be validated at run time when the whole select is built. In this collection we can have: 87 87 * !FdoIdentifier’s in case we just need to pass a class name. 88 * !FdoComputedIdentifier’s having a name and as expression value an !FdoIdentifier, this way we can get aliases, e.g. ! PropName AS !NewPropName. We already use computed identifiers in our API for expressions and we provide a name and an expression value. In this case it will be the same, since an alias is actually an expression: we provide an alias (name) and the real name of the property.88 * !FdoComputedIdentifier’s having a name and as expression value an !FdoIdentifier, this way we can get aliases, e.g. !ClassName AS !NewClassName. We already use computed identifiers in our API for expressions and we provide a name and an expression value. In this case it will be the same, since an alias is actually an expression: we provide an alias (name) and the real name of the class. 89 89 * !FdoClassComputedIdentifier’s which is a FdoISelect having a name. This option might not be supported by all RDBMS providers and it depends of the internal implementation. This class behaves like a computed class which will be evaluated at run time and really depends of the provider implementation. This new class will help to define sub-selects. Refer to '''Handle Sub-Selects''' below. 90 90 … … 308 308 e.g.: ''!FeatId IN (:PARAM)''. 309 309 310 Th '':PARAM'' parameter will be replaced at execution time with the sub-select statement. In this way we allow the FDO IN() operator to handle sub-selects.310 The '':PARAM'' parameter will be replaced at execution time with the sub-select statement. In this way we allow the FDO IN() operator to handle sub-selects. 311 311 312 312 As new additions, the FDO API will define three new classes: … … 392 392 == Future Enhancements == 393 393 394 If needed, similar extensions can be done to FDO Update, Delete, and other commands that use filters so that they can take advantage of sub-selects or SelectAggregates to take advantage of joins.394 If needed, similar extensions can be done to FDO Update, Delete, and other commands that use filters so that they can take advantage of sub-selects. 395 395 396 396 Other providers can be enhanced over time to implement these changes as needed.
