Thanks for all your hard work Romy!
-----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 23, 2010 12:53 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 Haris,
I've updated the RFC to include the changes we agreed till now.
Please have a look at the updated RFC and provide additional feedback.
What's new:
- we do have now a sub-select as an FdoExpression with all methods implemented.
- we have now only one new method in FdoISelect
Thanks,
Romy
________________________________________
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic [haris at sl-king.com]
Sent: Thursday, June 17, 2010 3:23 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
I think we are very much aware of that, we have discussed that in
many emails before.
In RFC sub-select is put into string as :SUBSEL and defined as FdoIdentifier
So, even now with current RFC filter with sub-select will not be serialized.
I think, we should discuss what is proper expression type or types for
sub-select.
Haris
On Wed, Jun 16, 2010 at 10:30 PM, Greg Boone <greg.boone at autodesk.com> wrote:
> LiterValue or ValueExpression... they both derive from FdoExpression, which is where the Process/Parse/ToString methods are defined.
>
>
> -----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 3:10 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
>
> Sub-Select is not literal value. I think it is value expression.
>
> Haris
>
> On Wed, Jun 16, 2010 at 9:04 PM, Greg Boone <greg.boone at autodesk.com> wrote:
>> Positioning is nice, but if these methods cannot be implemented easily, I doubt they will ever be implemented. The fact they probably won't be implemented implies the classes are not actually LiteralValues and thus should not be derived from that base class or from any base class that implements Parse/Process.
>>
>> Greg.
>>
>> -----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 2:58 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 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
>>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>
_______________________________________________
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