Changes between Version 33 and Version 34 of FDORfc50
- Timestamp:
- 06/24/10 12:25:43 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FDORfc50
v33 v34 43 43 * '''Cons''': We need to change all the providers leading to a big effort from everyone. 44 44 45 * Enhance FdoISelect, add a new method ''!GetJoinCriteria()'' with the default implementation of the method throwing an exception. Providers which want to implement this new method must override it 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 method 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 capabilities would be named: !SupportsJoins() & !GetJoinTypes(). A few other c nahes must be done in order to handle sub-selects.45 * Enhance FdoISelect, add a new method ''!GetJoinCriteria()'' with the default implementation of the method throwing an exception. Providers which want to implement this new method must override it 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 method 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 capabilities would be named: !SupportsJoins() & !GetJoinTypes(). A few other changes must be done in order to handle sub-selects. 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. … … 163 163 }}} 164 164 165 We need to add two new methods in connection capabilities: supports join selects (to avoid an exception when a user will try to use the new method from FdoISelect) and also supported join types which can be a collection or a value as OR between values, since all join types cannot be more than we can fit in a int32 using OR e.g.: val1|val2. 165 We need to add two new methods in connection capabilities: supports join selects (to avoid an exception when a user will try to use the new method from FdoISelect) and also supported join types which can be a collection or a value as OR between values, since all join types cannot be more than we can fit in a int32 using OR e.g.: val1|val2. We need to add an extra capability named SupportsSubSelects() since sub-select will be handled in filter side and applications might need a way to detect if it will allow users to create sub-selects in filter. 166 166 167 167 {{{ … … 170 170 virtual bool SupportsJoins(); 171 171 virtual FdoInt32 GetJoinTypes(); 172 virtual bool SupportsSubSelects(); 172 173 } 173 174 }}} … … 264 265 === Handle Sub-Selects === 265 266 266 Below we define a new class to define sub-select used in the new select. 267 Below we define a new class to define sub-select used in the new select. In case a provider supports sub-selects the capability SupportsSubSelects() should return true. 267 268 268 269 {{{ … … 566 567 * !SupportsJoins 567 568 * !GetJoinTypes 569 * !SupportsSubSelects 568 570 569 571 At FdoISelect::Execute time a feature reader will be returned, even though there might be cases when the join class returned by the reader will not contain a primary property or a geometry property. In cases where select commands do not provide a property selection list, all properties should be added to the feature class reader built at runtime. In cases where applications request a subset of properties, only those properties should be added to the feature class, even if that means the returned feature class might then contain no identity properties or geometry properties. In the worst case, a provider implementation can add all identity properties from the selected classes to the resulting identity property list of the joined class definition. Also, in case there is no way to return an identity property, providers can add a non-identity property to the identity property collection of the returned class as a shortcut to allow a primary property to be defined. (NOTE that the returned class will be read-only since there is no way to know if the resulting class can be updated.)
