[fdo-internals] New FDO RFC 50 posted - Extend FDO API to Select
from Multiple Classes and Select Joins
Haris Kurtagic
haris at sl-king.com
Wed Jun 16 14:58:17 EDT 2010
Hi Greg,
Certainly we are not trying to break concepts :)
In this RFC sub-select is introduced. We are trying to correctly
create support for sub-select in FDO.
Literal type and Parameter are already supported in FDO as value
expression. We want to add sub-select to it.
Romy is pointing out that to-string and parse from string want be easy
for sub-select.
I am pointing out that first concern is that we position and implement
sub-select correctly.
Haris
On Wed, Jun 16, 2010 at 5:29 PM, Greg Boone <greg.boone at autodesk.com> wrote:
> "For both classes FdoCollectionValue and FdoSubSelectValue we do not implement Parse, Process, ToString"
>
> -- This seems a bit wrong to me. LiteralValues by definition are parseable and processable. Why are we trying to force something into the API that breaks concepts designed into the API?
>
> Greg
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
> Sent: Wednesday, June 16, 2010 11:18 AM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] New FDO RFC 50 posted - Extend FDO API to Select from Multiple Classes and Select Joins
>
> Hi Haris,
>
> Yes you are right I wanted to say FdoComputedIdentifier and not FdoComputedClassIdentifier :). Thanks for pointing this out.
> With my proposal we remove/convert FdoComputedClassIdentifier into FdoSubSelectValue, so no more FdoComputedClassIdentifier.
> 1) I fixed the statement from below with the right class name:
> I used FdoComputedIdentifier to specify an alias for classes, FdoComputedIdentifier is designed for expressions and:
> - "CLSNAME AS MyClass" it is an expression
> - FdoComputedIdentifier is an identifier
> - Select command feature class set requires an identifier (see SetFeatureClassName)
> - No changes must be done in the API to use FdoComputedIdentifier for SetFeatureClassName
> - In case we call FdoComputedIdentifier::Create(L"parent", FdoIdentifier::Create(L"parcel"))->ToString(); we will get "parcel AS parent" which is exactly what we need.
> So I really think FdoComputedIdentifier is exactly what we need to make API call clear.
> We can use this way to specify aliases for properties also, e.g.:
> FdoComputedIdentifier::Create(L"FID", FdoIdentifier::Create(L"parent.fidPK"))->ToString(); = "parent.fidPK as FID"
>
> 2) Join criteria play the role of additional classes used in select. I would still like to have all properties in the same collection since in case I need to identify a source class I can use GetFeatureClassName or the criteria collection. His way I can add a join class and not select/expose any property from it, and just use properties in the filter side.
> Even if we go with multiple property collections where I can add an expression like: "child.fid * parent.fid AS SqFID"? How about filter we do have the same issue since I can mix properties from different sources (either main class or a join class).
> We could add multiple property collections in the end if you think is a critical issue, however it will create make API unclear since at one point I don't know where to add certain properties and expressions.
>
> 3) I don't have any problems to do that (FdoSubSelectValue:FdoValueExpression, FdoCollectionValue:FdoLiteralValue) with a few comments on what will involve here:
> - FdoLiteralValue has a method to return FdoLiteralValueType we need to update it and add FdoLiteralValueType_Collection
> - For both classes FdoCollectionValue and FdoSubSelectValue we do not implement Parse, Process, ToString. Methods will just throw an exception. I can see an implementation for FdoCollectionValue ("23, 34.45, 57"), however Process still cannot be implemented.
>
> Thanks,
> Romy.
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
> Sent: Wednesday, June 16, 2010 10:36 AM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] New FDO RFC 50 posted - Extend FDO API to Select from Multiple Classes and Select Joins
>
> Hi Romy,
>
> 1) Either me or you repeating same mistake
> In RFC http://trac.osgeo.org/fdo/wiki/FDORfc50
> FdoComputedClassIdentifier is introduced to define sub select not
> alias, right ?
>
>
> 2) We are adding new class FdoJoinCriteria into Select to define table
> to be joined and criteria to use it.
> I am suggesting that all things which are considering the join to
> be defined inside FdoJoinCriteria .
>
> 3) I think FdoSubSelectValue has to come from FdoValueExpression
> and FdoCollectionValue from FdoLiteralValue
>
> Regarding parsing FdoSubSelectValue I understand it would need extra
> work ( perhaps it could be left out too)
> I think it is much more important to be able to fully use sub-selects
> (like for update and insert) .
>
> Haris
>
> On Wed, Jun 16, 2010 at 3:38 PM, Romica Dascalescu
> <Romica.Dascalescu at autodesk.com> wrote:
>> Hi Haris,
>>
>> I have some additional comments:
>> 1) I used FdoComputedClassIdentifier to specify an alias for classes, FdoComputedClassIdentifier is designed for expressions and:
>> - "CLSNAME AS MyClass" it is an expression
>> - FdoComputedClassIdentifier is an identifier
>> - Select command feature class set requires an identifier (see SetFeatureClassName)
>> - No changes must be done in the API to use FdoComputedClassIdentifier for SetFeatureClassName
>> - In case we call FdoComputedClassIdentifier::Create(L"parent", FdoIdentifier::Create(L"parcel"))->ToString(); we will get "parcel AS parent" which is exactly what we need.
>> So I really think FdoComputedClassIdentifier is exactly what we need to make API call clear.
>>
>> 2) RE: "and also I don't think it is ok that in "main part" of select we set some undefined schema/alias selProps->Add(FdoIdentifier::Create(L"child.fid")); <-- wrong"
>> Comments:
>> - we cannot validate the requested properties so easily mostly because it's hard to get this information, we can have properties from upper selects and we know these properties only at execute time
>> - why complicate things and split in multiple property names when we actually ask for certain properties and we get a single class definition? This will complicate the code also leaves place for interpretation e.g.: what I can do if from a join I do not want to expose properties, I just want to use the result properties in filters only. In case I let that collection empty by FDO definition all properties are retrieved, in case I add a property I'm forced have to expose it.
>> - where do I have to put an expression like: "child.fid * parent.fid AS SqFID"? I'm asking that since we have properties from both classes (undefined schema/alias). Imagine: in case we really want to validate we have to search in 2+ property collections for a certain property and we might not find it since will come from a "select *"
>> So, we should not validate the selection list and use only one property collection, the one from select command to make the code simpler and API clear.
>>
>> 3) FdoSubSelectValue details
>>
>> We can create a complex type:
>> class FdoCollectionValue : public FdoIDisposable
>> {
>> public:
>> FdoCollectionValueType GetType() = 0;
>> void Reset() = 0; // reset will "move" the reader to initial position
>> void ReadNext() = 0; // read next value same as for a normal reader
>> FdoLiteralValue GetValue() = 0; // get the value from current position (can be called after ReadNext)
>> FdoDataType GetDataType() = 0;
>> }
>>
>> // class used to pass a sub select
>> class FdoSubSelectValue : public FdoCollectionValue
>> {
>> public:
>> FdoCollectionValueType GetType() {FdoCollectionValueType_SubSelect};
>> ///.....Now providers can work directly with FdoSubSelectValue or use the interfaceReadNext/GetValue
>> }
>>
>> // class used to pass collection of objects, e.g. {12.4, 34, 7, 789}
>> class FdoDataCollectionValue : public FdoCollectionValue
>> {
>> public:
>> FdoCollectionValueType GetType() {FdoCollectionValueType_DataCollection};
>> FdoDataType GetDataType(){};
>> ///.....
>> }
>> These classes cannot be a FdoLiteralValue because are parse-able and are not simple expressions (I don't see a way to implement Parse, Process, ToString).
>>
>> Thanks,
>> Romy.
>>
>> ________________________________________
>> From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
>> Sent: Wednesday, June 16, 2010 8:45 AM
>> To: FDO Internals Mail List
>> Subject: RE: [fdo-internals] New FDO RFC 50 posted - Extend FDO API to Select from Multiple Classes and Select Joins
>>
>> Hi Haris,
>>
>> I have a couple of comments below ...
>>
>> Thanks,
>> Orest.
>>
>> -----Original Message-----
>> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
>> Sent: Tuesday, June 15, 2010 5:17 PM
>> To: FDO Internals Mail List
>> Subject: Re: [fdo-internals] New FDO RFC 50 posted - Extend FDO API to Select from Multiple Classes and Select Joins
>>
>> Hi Romy,
>>
>> I suppose it is typo in example
>> "sel->SetFeatureClassName(FdoComputedClassIdentifier::Create(L"parent",
>> FdoIdentifier::Create(L"parcel")));" that it should be
>> "FdoComputedIdentifier" ?
>> I looked into FDO again and can see that up to now we used
>> "FdoComputedIdentifier" to put expression like "Length(Road) as Len"
>> into sql command (as it says in docs too).
>> I think that this shouldn't be used also as a way to say what is alias
>> for main class in a join.
>> I believe it is much clear to define necessary aliases in join
>> criteria and we don't change standard select command (part of defining
>> main class)
>>
>> So instead of
>> // solve the main class alias
>> sel->SetFeatureClassName(FdoComputedClassIdentifier::Create(L"parent",
>> FdoIdentifier::Create(L"parcel")));
>> we use unchanged (as up to now )
>> sel->SetFeatureClassName(L"parent");
>>
>> [OH] The alias that was included as part of the join criteria is the alias to use to reference the join result. But if we don't have a way to attach an alias to a class name that comes into the join, then how would we handle self joins as in the parcel example? Parent is not a class name but is intended as an alias name in this example, so sel->SetFeatureClassName(L"parent") wouldn't work because "parent" is not a class name. Strictly speaking, for the self-join on parcel, we don't need two aliases, "parent" and "child", but can get away with one alias such as "parent" and use "parcel" for the other part of the join, but it still needs to be specified.
>>
>>
>> and also I dont think it is ok that in "main part" of select we set
>> some undefined schema/alias
>> selProps->Add(FdoIdentifier::Create(L"child.fid")); <-- wrong
>>
>> I suggest that we define which properties to return from joined class
>> in same place where we define joined class
>> and that is FdoJoinCriteria.
>> so, it would be like:
>> // create the join criteria
>>> FdoPtr<FdoJoinCriteriaCollection> jcrit = sel->GetJoinCriteria();
>> ...
>> FdoPtr<FdoIdentifierCollection> joinProps = jc1 ->GetPropertyNames();
>> joinProps->Add(FdoIdentifier::Create(L"child.fid"));
>>
>> [OH] Interesting. So, then the complete set of properties returned by the select would be the union of all these collections? So, if I have two joins, then the properties returned would be the ones specified in the select identifier collection combined with the ones specified for each of the two join criteria?
>>
>> Before , I comment on subselect part I would like to ask, which class
>> you propose the new one "FdoSubSelectValue" will inherit ?
>>
>> Thanks,
>> Haris
>>
>> On Tue, Jun 15, 2010 at 5:58 PM, Romica Dascalescu
>> <Romica.Dascalescu at autodesk.com> wrote:
>>> Hi,
>>>
>>> There is an option when we create FdoParameterValue:
>>> - create a new class and wrap the FdoISelect
>>> - pass the FdoISelect directly to FdoParameterValue.
>>>
>>> Based on all comments till now I would do it like:.
>>>
>>> Thanks,
>>> Romy.
>>>
>>> FdoPtr<FdoISelect> sel = static_cast<FdoISelect*>(conn->CreateCommand(FdoCommandType_Select));
>>>
>>> // solve the main class alias
>>> sel->SetFeatureClassName(FdoComputedIdentifier::Create(L"parent", FdoIdentifier::Create(L"parcel")));
>>>
>>> // add selected properties
>>> FdoPtr<FdoIdentifierCollection> selProps = sel->GetPropertyNames();
>>> selProps->Add(FdoIdentifier::Create(L"parent.fid"));
>>> selProps->Add(FdoIdentifier::Create(L"child.fid"));
>>> selProps->Add(FdoIdentifier::Create(L"parent.geometry"));
>>>
>>> // create the join criteria
>>> FdoPtr<FdoJoinCriteriaCollection> jcrit = sel->GetJoinCriteria();
>>> FdoPtr<FdoFilter> jfilter = FdoFilter::Parse(L"parent.fid = child.parent_id");
>>> FdoPtr<FdoJoinCriteria> jc1 = FdoJoinCriteria::Create(L"child", FdoIdentifier::Create(L"parcel"), FdoJoinType_Inner, jfilter);
>>> jcrits->Add(jc1);
>>>
>>> // create sub-select
>>> FdoPtr<FdoISelect> subsel = static_cast<FdoISelect*>(conn->CreateCommand(FdoCommandType_Select));
>>> subsel->SetFeatureClassName(FdoIdentifier::Create(L"parcel_types"));
>>>
>>> // sub-select properties
>>> FdoPtr<FdoIdentifierCollection> subselProps = subsel->GetPropertyNames();
>>> subselProps->Add(FdoIdentifier::Create(L"type"));
>>>
>>> // set sub-select filter
>>> FdoPtr<FdoFilter> subselfilter = FdoFilter::Parse(L"category = 'x'");
>>> subsel->SetFilter(subselfilter);
>>>
>>> // optional we can create FdoSubSelectValue or we can pass FdoISelect (subsel)
>>> // FdoPtr<FdoSubSelectValue> subselval = FdoSubSelectValue::Create(subsel);
>>> FdoPtr<FdoParameterValueCollection> params = sel->GetParameterValues();
>>> params->Add(FdoParameterValue::Create(L"SUBSEL1", subsel));
>>>
>>> // set select filter
>>> FdoPtr<FdoFilter> filter = FdoFilter::Parse(L"child.area > 100 AND child.type IN (:SUBSEL1)");
>>> sel->SetFilter(filter);
>>>
>>> // execute
>>> FdoPtr<FdoIFeatureReader> rdr = sel->Execute();
>>>
>>>
>>> ________________________________________
>>> From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
>>> Sent: Tuesday, June 15, 2010 11:31 AM
>>> To: FDO Internals Mail List
>>> Subject: RE: [fdo-internals] New FDO RFC 50 posted - Extend FDO API to Select from Multiple Classes and Select Joins
>>>
>>> Hi Romy,
>>>
>>> Can you provide an example to illustrate the ideas you described below?
>>>
>>> Greg
>>>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
More information about the fdo-internals
mailing list