Changes between Version 6 and Version 7 of FDORfc50


Ignore:
Timestamp:
Jun 2, 2010, 11:28:13 AM (14 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc50

    v6 v7  
    3636
    3737    * Add a new select command e.g. FdoIJoinSelect derived from FdoISelect, add a new command type and caller needs to ensure that command exist in the provider command capabilities before calling this interface. A small improvement here we can add two classes FdoIJoinSelect (the interface having only pure methods) and !FdoJoinSelect (having a default implementation of those methods). All providers can use the class with a base implementation and in the future in case we want to add a new method we just add a default implementation in !FdoJoinSelect, however this adds more complexity to the API since developer would be confused which class should use as base class in his implementation.
    38         * '''Pro''': will not change the FdoISelect command, all other providers do not have to change anything on their side, and only in case a provider wants to support this command it has to implement it and expose it as supported.[[BR]]
     38        * '''Pros''': will not change the FdoISelect command, all other providers do not have to change anything on their side, and only in case a provider wants to support this command it has to implement it and expose it as supported.[[BR]]
    3939        * '''Cons''': We add a new command and a new type command, we already have a FdoIExtendedSelect for scrollable readers and users can be confused by those two commands. This will add more complexity in the API.
    4040
    4141    * Enhance FdoISelect, then create a !FdoSelect base class and add default implementers for !GetFeatureClassNames () and !GetJoinCriteria(). Then each provider would be changed to base their select command implementation on !FdoSelect instead of FdoISelect. Two new capability functions will be added so that applications can determine: if a provider supports the join criteria and supported join types, !SupportsJoins() & !GetJoinTypes(). Again, if future enhancements are ever made to FdoISelect, the need to change each provider would be eliminated.
    42           * '''Pro''': this solution will not add more complexity to the API.[[BR]]
     42          * '''Pros''': this solution will not add more complexity to the API.[[BR]]
    4343          * '''Cons''': We need to change all the providers leading to a big effort from everyone.
    4444
    4545     * Enhance FdoISelect, add two new methods ‘!GetFeatureClassNames()’ and ‘!GetJoinCriteria()’ with a default implementation throwing an exception. Providers which want to implement these new methods just can override then and provide a detailed implementation. Even FdoISelect is declared as ‘interface’ we do not have interfaces in C++ and we can have all other abstract methods and only the new one with a default implementation. A good example here would be locking methods from select command: most of the provider do not support locking and have to provide an empty implementation (usually to throw an exception), so more code on provider side when we could just provide a default implementation in the base class. Following this path we just modify the base class and all other providers will not be changed since 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.
    46          * '''Pro''': this solution will not add more complexity to the API, we do not need to change any provider.[[BR]]
     46         * '''Pros''': this solution will not add more complexity to the API, we do not need to change any provider.[[BR]]
    4747         * '''Cons''': None.
    4848
    … …  
    5353We need to define supported cases and all necessary classes need to be added:
    5454
    55 A. '''Selecting form multiple classes'''. 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 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:
    56     FdoIdentifier’s in case we just need to pass a class name.
    57     !FdoComputedIdentifier’s having a name and as expression value a 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.
    58     !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, see below case (C)
     55=== Selecting form Multiple Classes ===
     56
     57We should be able to select from multiple classes and have filters applied on any class attributes. In order to be able to achieve that 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:
     58    * FdoIdentifier’s in case we just need to pass a class name.
     59    * !FdoComputedIdentifier’s having a name and as expression value a 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.
     60    * !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, see below case (C)
    5961
    6062We will use some SQL examples just to illustrate things we are trying to achieve, each RBDMS-based provider will translate FDO selects in server side SQL depending of the server capabilities.
    … …  
    8587
    8688
    87 
    88 B. '''Handle Joins''' : below we define new classes to define and use a join criteria used in the join select.
     89=== Handle Joins ===
     90
     91Below we define new classes to define and use a join criteria used in the join select.
    8992
    9093{{{
    … …  
    177180Join criteria will be used to generate join SQL commands, like:
    178181
    179 '''SELECT p.FeatId AS xFID,p.Geometry,pxy.Name,pxy.X,pxy.Y,pex.NameB,pex.Link FROM p '''[[BR]]
    180 '''INNER JOIN pxy ON(p.FeatId = pxy.FeatId)'''[[BR]]
    181 '''INNER JOIN pex ON(pex.FID = pxy.FeatId)'''[[BR]]
    182 '''WHERE p.FeatId >= 0;'''[[BR]]
     182'''SELECT p.!FeatId AS xFID,p.Geometry,pxy.Name,pxy.X,pxy.Y,pex.NameB,pex.Link FROM p '''[[BR]]
     183'''INNER JOIN pxy ON(p.!FeatId = pxy.!FeatId)'''[[BR]]
     184'''INNER JOIN pex ON(pex.FID = pxy.!FeatId)'''[[BR]]
     185'''WHERE p.!FeatId >= 0;'''[[BR]]
    183186
    184187Below we added some C++ code on how caller can use this new improvement to achieve above select statement:
    … …  
    208211
    209212
    210 
    211 C. '''Handle Sub-selects''' : below we define a new class to define sub-select used in the new select.
     213=== Handle Sub-selects ===
     214
     215Below we define a new class to define sub-select used in the new select.
    212216
    213217{{{
    … …  
    244248
    245249In above case we will have two selects having following filters:
    246     Main select:  “!FeatId IN(:SUBSEL)”
    247     Sub-select: “pt.!FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL)”
     250    * Main select:  “!FeatId IN(:SUBSEL)”
     251    * Sub-select: “pt.!FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL)”
    248252
    249253Below we added some C++ code on how caller can use this new improvement to achieve above select statement:
    … …  
    272276}}}
    273277
    274 In order to be able to support sub-selects for '''IN''' operator we need provide a way to pass it through FDO Filter and make the parser to recognize the filter, since FDO Filter parser don’t know SQL syntax. The best way to achieve that is to pass a parameter in the filter, e.g.: '''FeatId IN(:PARAM)'''. This parameter will be replaced by the provider at execution time by the sub-select. This way we improve IN() operator in FDO to handle sub-selects.
    275 
    276 
    277 As new additions to the FDO API we will have three new classes (FdoJoinCriteria, FdoJoinCriteriaCollection and FdoComputedClassIdentifier) and two enumerations (FdoItemExpressionType and FdoJoinType). We also need to add a new two new command capabilities, two new methods SupportsJoins and GetJoinTypes in order to be able to detect if those methods are supported by the provider (otherwise caller might get exceptions from the default implementation).
     278In order to be able to support sub-selects for '''IN''' operator we need provide a way to pass it through FDO Filter and make the parser to recognize the filter, since FDO Filter parser don’t know SQL syntax. The best way to achieve that is to pass a parameter in the filter, e.g.: '''!FeatId IN(:PARAM)'''. This parameter will be replaced by the provider at execution time by the sub-select. This way we improve IN() operator in FDO to handle sub-selects.
     279
     280
     281As new additions to the FDO API we will have three new classes (!FdoJoinCriteria, !FdoJoinCriteriaCollection and !FdoComputedClassIdentifier) and two enumerations (!FdoItemExpressionType and !FdoJoinType). We also need to add a new two new command capabilities, two new methods !SupportsJoins and !GetJoinTypes in order to be able to detect if those methods are supported by the provider (otherwise caller might get exceptions from the default implementation).
    278282
    279283We are planning at execute time to return a feature reader even there might be cases when the class returned by the reader might not have a primary key or a geometry column. In case select do not provide a select property list, all returned columns will be added to the feature class reader built at runtime, however in case user will request certain properties only those properties will be added to the feature class and even returned feature class might have no primary key or no geometry, depending of caller request. A feature reader is way more useful in applications. In the worst case we can add all primary keys from the selected classes to the result primary key of the class. Also in case there is no way to return a primary key user can add one of the property to the primary key collection of the returned class to have a primary key. The returned class will be read-only since there is no way to know what we can update.
    … …  
    285289== Small improvements in FDO ==
    286290
    287 '''Handling FDO expressions to avoid dynamic casts'''
    288 
    289 In the current API in order to make a difference between FdoIdentifier and FdoComputedIdentifier we need to use dynamic cast and that’s not too fast. There is a simple way to avoid many dynamic casts by adding a new abstract method in FdoExpression named GetExpressionType(). All main derivate classes from FdoExpression need to return a type without adding a new parameter this way we avoid increasing the memory consumption by FDO expression objects. A new enumeration will be added, see below, and classes like FdoIdentifier will have to implement this method.
     291=== Handling FDO expressions to avoid dynamic casts ===
     292
     293In the current API in order to make a difference between !FdoIdentifier and !FdoComputedIdentifier we need to use dynamic cast and that’s not too fast. There is a simple way to avoid many dynamic casts by adding a new abstract method in !FdoExpression named !GetExpressionType(). All main derivate classes from !FdoExpression need to return a type without adding a new parameter this way we avoid increasing the memory consumption by FDO expression objects. A new enumeration will be added, see below, and classes like !FdoIdentifier will have to implement this method.
    290294
    291295{{{
    … …  
    323327}}}
    324328
    325 '''Update the FDO Filter to handle custom names'''
    326 
    327  FDO filter parser needs to be updated since we support only Class.Property e.g.: "A.BB >=10". We need to support also formats like:
     329=== Update the FDO Filter to handle custom names ===
     330
     331FDO filter parser needs to be updated since we support only Class.Property e.g.: "A.BB >=10". We need to support also formats like:
    328332        ||Class."Property"||
    329333        ||"Class".Property||