Changes between Version 23 and Version 24 of FDORfc50


Ignore:
Timestamp:
Jun 3, 2010, 11:36:02 AM (14 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FDORfc50

    v23 v24  
    4949== Proposed Solution ==
    5050
    51 The last option seems to be the best solution since will not enforce other providers to add a blank implementation for those new methods and also will not add a new command. We avoid having two select commands one “extended” and one “join” this way we also eliminate a confusion which might show-up in commands naming. Also it opens a different approach to update a base class without changing all providers to add a blank implementation.
     51The last option seems to be the best solution since will not enforce other providers to add a blank implementation for those new methods and also will not add a new command. We avoid having two select commands one "extended" and one "join" this way we also eliminate a confusion which might show-up in commands naming. Also it opens a different approach to update a base class without changing all providers to add a blank implementation.
    5252
    5353The new methods added on FdoISelect will have a default implementation throwing an exception:
     
    8484=== Selecting form Multiple Classes ===
    8585
    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 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:
     86We 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:
    8787    * !FdoIdentifier’s in case we just need to pass a class name.
    8888    * !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.
    8989    * !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.
    9090
    91 We 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.
     91The following sections 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.
    9292
    9393    ''SELECT * FROM class1 AS p1, class2 AS p2 WHERE p1.ID=p2.!FeatId AND SPATIAL_COND(p1.GEOM, GEOM_VAL);''
     
    277277In above case we will have two selects having following filters:
    278278    Main-Select: ''!FeatId IN(:SUBSEL)''[[BR]]
    279     Sub-Select: ''pt.!FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL)''
     279    Sub-Select : ''pt.!FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL)''
    280280
    281281Below we added some C++ code on how caller can use this new improvement to achieve above select statement:
     
    304304}}}
    305305
    306 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.
     306In 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.
     307
     308    e.g.: ''!FeatId IN (:PARAM)''.
     309
     310Th '':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.
    307311
    308312As new additions, the FDO API will define three new classes: