[fdo-internals] New FDO RFC 50 posted - Extend FDO API to
Select from Multiple Classes and Select Joins
Orest Halustchak
orest.halustchak at autodesk.com
Wed Jun 16 08:45:14 EDT 2010
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(FdoComputedClassIdentifier::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
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
> Sent: Tuesday, June 15, 2010 9:34 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 think we can extend the select (as you said) by removing GetFeatureClassNames() and keeping only join criteria collection.
>
> A few answers and proposal for below items:
>
> (1) We should not mix aliases of the main class in joins. Main alias class name can be provided as a Computed identifier and this way we get rid of AddAlias() from join criteria. Provider/select command don't have to keep any mapping this way. Filter can use the alias since server will complain if something is not right there. So, no AddAlias() method and keep everything we have and it will work.
>
> (2)&(3) I think we should not add a new collection and method to the Filter. We can do what we proposed without changing the API too much.
>
> We can use GetParameterValues() from select command rather to add a new collection to the filter.
> class FdoICommand : public FdoIDisposable
> {
> FDO_API virtual FdoParameterValueCollection* GetParameterValues() = 0;
> }
>
> In filter/expression processor we can process only simple types, like : FdoBooleanValue, FdoByteValue, FdoDateTimeValue, FdoDecimalValue, FdoDoubleValue, FdoInt16Value, FdoInt32Value, FdoInt64Value, FdoSingleValue, FdoStringValue, FdoBLOBValue, FdoCLOBValue, FdoGeometryValue. The expression values can really show in expressions or filters only.
>
> Regarding a parameter we can even have it in an expression or filter, however the parameter how up only as name and not as value also, e.g.:
> 'FeatId IN (:MYPARAM)'
> 'FeatId * :MYPARAM'
>
> Expression and Filter processors can Process only parameters and not parameter values. Parameters contain only the name which should/can be replaced/bonded at runtime with a value (or an expression).
> Parameter value have a name and a value (which can be an expression also - not supported yet), which right now can be a simple value only, from above list. Parameter value will never be processed by calling Process or Parse mainly because the parameter values cannot be saved to text.
>
> I can say our API is somehow limited because we can pass only a simple value for a parameter. We can pass more if we change Parameter value definition.
> Now using the parameter value class as it is we cannot pass a collection of values e.g.: I have a filter like 'FeatId IN(:MYCOLL)' and I want pass a parameter value having a collection of numbers {12, 44, 88898, 23457435}.
>
> So we should update/modify FdoParameterValue class to accept other types of "values" and not only FdoLiteralValue (add a new constructor and a few other methods)
> We could create a new type e.g. FdoSubSelectValue &/ FdoCollectionValue which can be used by provider to bind the parameter. In the end we will be able to use this class for insert, update and delete.
> We should not change FdoLiteralValue, we should just define a new type of expression and this way we do not change our FDO simple values and expressions.
> Doing that the new type can or cannot support ToString or Parse and we are not tide of the definition of simple FDO expression/value.
>
> class FdoParameterValue : public FdoIDisposable
> {
> protected:
> FdoParameterValue(FdoString* name, FdoSubSelectValue* value);
>
> FdoParameterValue(FdoString* name, FdoCollectionValue* value); // future use
> public:
> FDO_API static FdoParameterValue* Create(FdoString* name, FdoSubSelectValue* value);
>
> FDO_API static FdoParameterValue* Create(FdoString* name, FdoCollectionValue* value); // future use
> }
>
> 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 10, 2010 10:58 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,
>
> 1) Defining alias is already part of RFC (trough constructor). RFC
> suggested that aliases which are used in Join Filter are defined
> separately. One in base select another in FdoJoinCriteria.
> My suggestion is that both alias which are used in Join Filter are
> defined in Join Criteria itself.
>
> FdoFilter parser which will support Join will implement mapping
> between alias used in Filter and actual generated SQL statement.
> Some type of mapping/control would be necessary also in original RFC
> regarding used-duplicated aliases.
>
> I think main difference comes from: I want for provider to see which
> tables are used and that provider will be able to easily decide which
> actual alias in SQL to use ( not to use alias defined in Filter).
>
> BTW, Greg send sample with self join and extra AddAlias was necessary,
> otherwise if it was not self join extra AddAlias wouldn't be needed.
>
> 2) As said in RFC for Filter "FdoFilter::Parse(L"FeatId IN
> (:SUBSEL1)");" :SUBSEL1 needs to be set and it will be done during
> execution.
> My suggestion is that instead of defining "AddParameter" on filter
> implementation we add standard AddParameter (or simillar) to Filter.
>
> I don't see why current providers would change because of that.
>
> 3) I am afraid I didn't understood your suggestion.
> If sub-select is based on expression, then provider can when creating
> SQL for insert not only use number, string etcc as value but put
> sub-select in SQL statement.
>
>
>
> Haris
>
>
>
> On Thu, Jun 10, 2010 at 3:40 PM, Romica Dascalescu
> <Romica.Dascalescu at autodesk.com> wrote:
>> Hi Haris,
>>
>> I have a few comments about your approach:
>>
>> 1) I see you include a new function on FdoJoinCriteria to add aliases. I might not fully understand the proposal, could you please elaborate how this would work?
>>
>> The alias is for the main class, but we can have more than a single FdoJoinCriteria in the select.
>> - What will happen when every FdoJoinCriteria will provide an (different) alias for the main class?
>> - What will happen when every/one FdoJoinCriteria will provide more than one alias for the main class?
>>
>> 2) I see now we have a new function on the FdoFilter named AddParameter.
>>
>> This will generate many changes, also a filter can be returned by a parser and FdoComputedClassIdentifier, can be created only using the API. (We might open the Pandora Box here... )
>>
>> I fear we may be too adventurous in providing values for parameters in a filter. Many filter processing implementations will have to be updated to support such a change. I would like to avoid forcing applications and providers to make updates unless absolutely necessary.
>>
>> 3) For property values having a select statement as source (used in insert/update). Can we defer this change to a secondary RFC?
>>
>> I propose...
>>
>> - Creating a new class FdoPropertyComputedValue (derived from FdoPropertyValue), which will take, in the constructor, a name and an FdoISelect or an FdoComputedClassIdentifier.
>> - At run time in the provider I would call Execute() and ReadNext()
>> - Get value by value from the returned reader and execute the insert.
>>
>> In FDO API we separate identifiers from property values. FDO even do not support FDO expressions (e.g. "Prop1 + Prop2") in property values. It will be a nice addition to support FDO expressions or select commands in property values, but I believe we should create special classes in order to have a clear API.
>>
>> 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: Tuesday, June 08, 2010 3:49 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
>>
>> I have another suggestion too, but didn't wanted to change previous
>> sample to much
>>
>> for sub-select like in your previous example 'select type from
>> parcel_types where category = 'x''
>> in RFC new class is defined:
>> class FdoComputedClassIdentifier : public FdoIdentifier {...}
>>
>> but I think that is wrong type of expression for that select. It is
>> value not identifier.
>>
>> so , my suggestion would be to define class like FdoSelectValue :
>> public FdoValueExpression {...}
>>
>>
>> Big plus would be that as it is, sub-select could be used in updates
>> and inserts too. That would be very useful.
>>
>> Haris
>>
>> On Tue, Jun 8, 2010 at 9:42 PM, Haris Kurtagic <haris at sl-king.com> wrote:
>>> you gave me homework. I tried to wrote it accurately, hope to get
>>> passing grade :)
>>> I would say key points are:
>>> - select stay unchanged for standard non-join select's
>>> - in join criteria itself describe all what is necessary for join to be created
>>> - don't push provider what aliases to use
>>> - instead of passing parameters to filter "at execution time" define
>>> them clearly at interface level
>>>
>>> // standard select
>>> FdoPtr<FdoISelect> sel =
>>> static_cast<FdoISelect*>(conn->CreateCommand(FdoCommandType_Select));
>>> FdoPtr<FdoIdentifierCollection> selProps = sel->GetPropertyNames();
>>> sel->SetFeatureClassName("parcel");
>>> selProps->Add(FdoIdentifier::Create(L"fid"));
>>> selProps->Add(FdoIdentifier::Create(L"geometry"));
>>>
>>> // describe things join needs to know in join
>>> // don't push alias to be used to provider. instead leave describe
>>> provider what aliases are and let provider what aliases to use in
>>> actual SQL
>>> // I would change FdoJoinCriteria this further to look even more
>>> familliar to standard select ( SetFilter, etc..)
>>> 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);
>>> jc1->AddAlias("parent",FdoIdentifier::Create(L"parcel"));
>>> FdoPtr<FdoIdentifierCollection> selPropsChild = jc1->GetPropertyNames();
>>> selPropsChild->Add(FdoIdentifier::Create(L"fid"));
>>> jcrits->Add(jc1);
>>>
>>> FdoPtr<FdoISelect> subsel =
>>> static_cast<FdoISelect*>(conn->CreateCommand(FdoCommandType_Select));
>>> FdoPtr<FdoIdentifierCollection> subselProps = subsel->GetPropertyNames();
>>> subselProps->Add(FdoIdentifier::Create(L"type"));
>>> sel->SetFeatureClassName("parcel_types");
>>> FdoPtr<FdoFilter> subselfilter = FdoFilter::Parse(L"category = 'x'");
>>> subsel->SetFilter(subselfilter);
>>>
>>> // instead of as stated in RFC "The :PARAM parameter will be replaced
>>> at execution time with the sub-select statement."
>>> // define those parameters clear at interface level
>>> FdoPtr<FdoFilter> filter = FdoFilter::Parse(L"child.area > 100 AND
>>> child.type IN (:SUBSEL1)");
>>> FdoPtr<FdoComputedClassIdentifier> fcSubSelParam =
>>> FdoComputedClassIdentifier::Create(L"SUBSEL1", subsel);
>>> filter->AddParameter(fcSubSelParam);
>>> sel->SetFilter(filter);
>>>
>>> FdoPtr<FdoIFeatureReader> rdr = sel->Execute();
>>>
>>> On Tue, Jun 8, 2010 at 7:42 PM, Greg Boone <greg.boone at autodesk.com> wrote:
>>>> Hi Haris,
>>>>
>>>> Based on you recommendations, could you put together a code example of how the following join would be handled?
>>>>
>>>> Select parent.fid, child.fid, parent.geometry from (parcel as parent) inner join (parcel as child) on parent.fid = child.parent_id Where child.area > 100 and child.type in (select type from parcel_types where category = 'x')
>>>>
>>>> Here is how it would look (roughly) based on the current RFC:
>>>>
>>>> FdoPtr<FdoISelect> sel = static_cast<FdoISelect*>(conn->CreateCommand(FdoCommandType_Select));
>>>> 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"));
>>>>
>>>> FdoPtr<FdoIdentifierCollection> fclasscoll = sel->GetFeatureClassNames();
>>>> fclasscoll->Add(FdoComputedClassIdentifier::Create(L"parent", FdoIdentifier::Create(L"parcel")));
>>>>
>>>> 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);
>>>>
>>>> FdoPtr<FdoISelect> subsel = static_cast<FdoISelect*>(conn->CreateCommand(FdoCommandType_Select));
>>>> FdoPtr<FdoIdentifierCollection> subselProps = subsel->GetPropertyNames();
>>>> subselProps->Add(FdoIdentifier::Create(L"type"));
>>>> FdoPtr<FdoIdentifierCollection> fclasscollsubsel = subsel->GetFeatureClassNames();
>>>> fclasscollsubsel->Add(FdoIdentifier::Create(L"parcel_types"));
>>>> FdoPtr<FdoFilter> subselfilter = FdoFilter::Parse(L"category = 'x'");
>>>> subsel->SetFilter(subselfilter);
>>>>
>>>> fclasscoll->Add(FdoComputedClassIdentifier::Create(L"SUBSEL1", subsel));
>>>>
>>>> FdoPtr<FdoFilter> filter = FdoFilter::Parse(L"child.area > 100 AND child.type IN (:SUBSEL1)");
>>>> sel->SetFilter(filter);
>>>>
>>>> FdoPtr<FdoIFeatureReader> rdr = sel->Execute();
>>>>
>>>> Cheers,
>>>> 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: Tuesday, June 08, 2010 1:31 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
>>>>
>>>> Using Join user certainly has to be able to set which properties has
>>>> to be returned.
>>>>
>>>> "multiple class select" and/or "join", I would expect that is same
>>>>
>>>> I wasn't writting about parsing SQL at all.
>>>>
>>>> In RFC FdoComputedClassIdentifier is define as FDO expression, right ?
>>>> FDO Expression is part of FDO filter, right ?
>>>>
>>>> Haris
>>>>
>>>> On Tue, Jun 8, 2010 at 4:31 PM, Romica Dascalescu
>>>> <Romica.Dascalescu at autodesk.com> wrote:
>>>>>
>>>>> Having a join will force provider to generate a join code and return all properties of those classes. Some properties might be selected only to use them in Filters and not as returned properties (user might chose to do that with "private" data which cannot be shared in a data grid however those can be used in filters)
>>>>> Implementing a select against multiple classes I can chose the properties returned.
>>>>>
>>>>> Regarding sub-select "IN()" FDO parser don't know to parse SQL, so it will not be the same as FeatId IN (2,3)
>>>>>
>>>>> Re 2.: Adding a computed class in select list will make all properties returned by the sub-select to be returned and that's not good since I might need them fro Where clause, e.g.:
>>>>> SELECT a1.FeatId, A2.Geom, A3.Name FROM A1, A2, (select V1, Name FROM Class5 WHERE COND2) AS A3 WHERE A3.V1=A2.V1 AND COND1
>>>>>
>>>>> 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: Tuesday, June 08, 2010 10:28 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
>>>>>
>>>>> For 3 or more classes we use more FdoJoinCriteria as in sample in RFC
>>>>> "Handling Joins"
>>>>> Use 2 or more FdojoinCriteria.
>>>>> In sample "FdoPtr<FdoIdentifierCollection> fclasscoll = =
>>>>> sel->GetFeatureClassNames();" is used to set only name of the first
>>>>> class. Could be SetFeatureClassName as well.
>>>>>
>>>>>
>>>>> Sub-Select doesn't need to be defined in join at all. It will be part
>>>>> of filter. It is expression.
>>>>> Same as I would set filter FeatId IN (2,3) or FeatId = 2.
>>>>>
>>>>> Haris
>>>>>
>>>>> On Tue, Jun 8, 2010 at 4:17 PM, Romica Dascalescu
>>>>> <Romica.Dascalescu at autodesk.com> wrote:
>>>>>> Hi Haris,
>>>>>>
>>>>>> A few comments below:
>>>>>>
>>>>>> Re: 1. When we create Joins we can use SetFeatureClassName and FdoJoinCriteria
>>>>>>
>>>>>> Re: 2. How this will work? since we have samples like: SELECT * FROM point WHERE FeatId IN (SELECT pt.FeatId FROM pt WHERE COND) and the FdoComputedClassIdentifier is not in the select list.
>>>>>>
>>>>>> Removing GetFeatureClassNames wow we can select from 3 classes? e.g.:
>>>>>> SELECT a1.FeatId, A2.Geom, A3.Name from A1, A2, A3 [ - optional WHERE COND]
>>>>>>
>>>>>> Each SQL statement have columns and the providers will generate a feature class definition same as SQLite is doing right now.
>>>>>>
>>>>>> 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: Tuesday, June 08, 2010 10:04 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 will try to summarize couple of my suggestions :
>>>>>>
>>>>>> 1. To not have SetFeatureClassName and GetFeatureClassNames to set classes
>>>>>> Just use SetFeatureClassName in base select and FdoJoinCriteria to
>>>>>> define joins.
>>>>>>
>>>>>> 2. Use sub-select as newly introduced FdoComputedClassIdentifier class
>>>>>> (change name) as property value too in property list.
>>>>>> I would also suggest to investigate / test use of the class in
>>>>>> insert and updates but as value (not as filter).
>>>>>> I have feeling it may just work.
>>>>>>
>>>>>> Two for now :)
>>>>>>
>>>>>> BTW, regarding feature class which is supposed to be generated after
>>>>>> executing select command we had issues before and we discuss it. Also
>>>>>> from text in this RFC it seems that it is very unclear what resulting
>>>>>> class should look like in many cases. It is pretty unclear that It
>>>>>> seems almost equally good to leave class def empty.
>>>>>> I am not suggesting to change it now. Just pointing out to the issue
>>>>>> which has repeated itself few times.
>>>>>>
>>>>>> Thank you,
>>>>>> Haris
>>>>>>
>>>>>> On Tue, Jun 8, 2010 at 2:29 PM, Orest Halustchak
>>>>>> <orest.halustchak at autodesk.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks Haris for the comments. Some more feedback below ...
>>>>>>>
>>>>>>> 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: Monday, June 07, 2010 7:24 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
>>>>>>>
>>>>>>> I have feeling that we perhaps misunderstood on few questions
>>>>>>> (basically not questions but more call to discuss it more then it is
>>>>>>> written in RFC already )
>>>>>>> I don't know if i am able to add comment into those inlines but will try
>>>>>>>
>>>>>>> Haris
>>>>>>>
>>>>>>> On Tue, Jun 8, 2010 at 12:44 AM, Romica Dascalescu
>>>>>>> <Romica.Dascalescu at autodesk.com> wrote:
>>>>>>>> Hi Haris,
>>>>>>>>
>>>>>>>> Thank you for your comments Haris. Below ([RD]) you can find a few answers for your questions.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> 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: Monday, June 07, 2010 4:40 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 ,
>>>>>>>>
>>>>>>>> I am glad that you are putting effort into this RFC. This RFC is
>>>>>>>> certainly needed.
>>>>>>>> It is also quite big topic and enhancement to FDO.
>>>>>>>> I read it couple of times and have few question / remarks. I am pretty
>>>>>>>> sure there will be more of it.
>>>>>>>>
>>>>>>>> 1. I prefer abstract functions. When I recompile providers for new
>>>>>>>> version it helps me remind there is something new (at least).
>>>>>>>> [RD] This involves that we have to 'fix' all providers to add a (the same) default implementation for these two new methods. Having a default implementation like AddRef & Release will lead to not modify providers which do not support such select.
>>>>>>> [HK] with new FDO version providers will be rebuild and couple of
>>>>>>> abstract functions definition doesn't heart and I can see error in
>>>>>>> compile as motivation to implement it more ... but that is not so
>>>>>>> important for this rfc
>>>>>>>>
>>>>>>>> 2. There had to be some cons on proposed solution :)
>>>>>>>> [RD] I thought about cons but I could not find one. Did you have some other than above statement?
>>>>>>>>
>>>>>>>> 3. SetFeatureClassName of FeatureCommand will be left unused and that
>>>>>>>> sounds like a bit confusing API
>>>>>>>> [RD] True, but we did not find a nice way to be able to set more feature class names. In order to make that possible we need a collection, one solution would be to "convert"/remove SetFeatureClassName and use only GetFeatureClassNames, but this will generate a huge change in the providers side, or add a separated command...
>>>>>>> [HK] perhaps GetFeatureClassNames is not necessary at all
>>>>>>>
>>>>>>> [OH] GetFeatureClassNames is needed to be able to specify a collection of class names to use. But, it would only be used for providers that support the new functionality. Also, we need to maintain backwards compatibility, so we end up with both FeatureClassName and FeatureClassNames. Is there an alternative idea that doesn't break backwards compatibility (for existing applications that are using the api)?
>>>>>>>
>>>>>>>>
>>>>>>>> 4. In "Selecting from Multiple Classes" example when I saw example and
>>>>>>>> read that it was mentioning "aliases"
>>>>>>>> My first taught is that FdoComputedIdentifier is used to define
>>>>>>>> aliases for names used in filter not to be used as actual alias in
>>>>>>>> generated SQL statement. Am I right here ? If not I see lot of
>>>>>>>> problems in user defining actual alias for SQL statement.
>>>>>>>> 5. Why using alias at all ? Shouldn't be name of the class way to go ?
>>>>>>>> [RD] Yes and no. The idea is we can get rid of aliases for classes, however for properties is good to keep them because in case we select from two feature classes and those classes have a property named the same (e.g. FeatId) we will have a name conflict (FDO API do not allow two properties with the same name in a property collection). This way we offer to the user a way to rename properties to avoid such cases. In the end alias is an expression :)
>>>>>>> [HK] I still don't understand , why use aliases ? why not use
>>>>>>> class.property or schema.class.property in filter ? If using aliases
>>>>>>> then user need to use what in property list or order list
>>>>>>> (class.property or alias.property )?
>>>>>>>
>>>>>>> [OH] Aliases allow you to specify self-joins in cases where classes have references back to themselves. If I include the same class name twice in the list, I need aliases to distinguish the first one from the second one.
>>>>>>>
>>>>>>>>
>>>>>>>> 6. How we select which properties to be returned ? All properties from
>>>>>>>> all class names from GetFeatureClassNames by deafult ?
>>>>>>>> [RD] Same as now: in case we do not specify any property all properties are returned (select * from...), in case caller adds some properties in collection GetPropertyNames() then only those properties will be selected.
>>>>>>>>
>>>>>>>> 7. How we name properties to be returned (again alias/class name ?) ?
>>>>>>>> Same question for ordering properties ?
>>>>>>>> [RD] Here caller needs to be a bit careful: in case a property exist in both classes then it must be provided with class name in the front in filter or select collection. In the returned feature class the original class name is removed and in case an alias is provided we return alias name and not property name. I think here is a provider implementation decision, e.g. in case we have a name conflict provider either can throw an exception or generate a name on the fly for that property.
>>>>>>>>
>>>>>>>> 8. Why we have two ways for "Selecting from Multiple Classes" and
>>>>>>>> "Handling Joins" ? Could be same interface ?
>>>>>>>> [RD] There are 3 examples "Selecting from Multiple Classes", "Handling Joins" and "Handle Sub-Selects", we do not have different interfaces for them. I just provided examples what we can/want to do with proposed changes.
>>>>>>> [HK] Yes there are 3 in RFC. I am saying why not use FdoJoinCriteria
>>>>>>> only for first two cases/samples? In that case GetFeatureClassNames
>>>>>>> doesn't need to be added into base class.
>>>>>>>>
>>>>>>>> 9. I believe example in "Handling Joins" is missing implemented filter
>>>>>>>> "WHERE p.FeatId >= 0;"
>>>>>>>> [RD] I will update the example.
>>>>>>>>
>>>>>>>> I like sub-queries.
>>>>>>>>
>>>>>>>> 10. I don't like name of new expression type "ComputedClassIdentifier" as it can be treated as property too
>>>>>>>> [RD] This is a sub-select and can behave like a source to select so we can named computed. Imagine a select like:
>>>>>>>> "SELECT * FROM cls1, (SELECT * FROM C1, C2 WHERE Filter1) AS cls2 WHERE cls1.FeatId = cls2.FeatId;
>>>>>>>> The computed class is actually cls2 having the definition "SELECT * FROM C1, C2 WHERE Filter1"
>>>>>>> [HK] Sub-Query is also "SELECT Property FROM C1, C2 WHERE Filter1" and
>>>>>>> it is value. In such case can be used as value in select part of
>>>>>>> statement or insert, update as value.
>>>>>>>
>>>>>>> [OH] We could call it just "ComputedIdentifier". So, your idea is to allow that computed identifier to be added to the select property list?
>>>>>>>
>>>>>>>>
>>>>>>>> 11. Why sub-query FdoISelect is not using standard SetFeatureClassName in example ? It is non-join select.
>>>>>>>> [RD] In the example we just wanted to show how we can use the new methods, in case caller has only one class to select from then he can use SetFeatureClassName, however in case we have a join select or a select from multiple classes then we need to use the new methods.
>>>>>>> [HK] But Sub-query is simple query. Recommended would be to use
>>>>>>> "standard" SetFeatureClassName? We come again to little confusion
>>>>>>> about where we can set class names.
>>>>>>>>
>>>>>>>> 12. Haven't checked at class defs but this sub-queries should be accepted in property list to be returned as well as to be accepted as values for update and insert
>>>>>>>> [RD] We could improve update, insert and delete (by adding this collection) but we said we can keep it as a future enhancement (limited time to implement this).
>>>>>>> [HK] If sub-query is treated as property value . I have feeling that
>>>>>>> it would be very simple to use it as part of insert or update value.
>>>>>>> Actually, I could imagine that it could just work right now as it is.
>>>>>>>
>>>>>>> [OH] There are a number of commands that use filters that possibly could be improved to support sub-selects. As Romy said, it seemed that we could leave those for another RFC rather than trying to do it all at once.
>>>>>>>
>>>>>>>>
>>>>>>>> Perhaps a bit off this RFC but it was mentioned in the RFC ( in a bit scary way).
>>>>>>>> I think that reader shouldn't bother to return FDO class. Reader should be able to return count, name, type of properties,... in it but not to generate some fictive FDO class.
>>>>>>>> [RD] In many cases a feature reader will be more useful than a normal reader. To return count in many cases would mean to execute the select and get the count: e.g. select COUNT(*) from (our select statement). This approach will not be fast since aggregate functions are not too fast from some providers. Aggregate select can be used in this case, if count is needed.
>>>>>>> [HK} With count I mean number of properties in reader.
>>>>>>>
>>>>>>> [OH] We have separate commands, Select versus SelectAggregates, for returning features and just non-feature data. So, to keep the Select command as returning features, even computed features, it should return a feature reader.
>>>>>>>
>>>>>>>>
>>>>>>>> If application needs it, application will generate FDO class for it's use ( it can be even utility in fdo itself).
>>>>>>>
>>>>>>> [OH] I agree that would be a useful utility, but I think it's a separate topic. The Select command already returns a feature reader and I don't think we should change that.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> And, thank you for working on this RFC.
>>>>>>>>
>>>>>>>> Haris
>>>>>>>>
>>>>>>>> On Fri, Jun 4, 2010 at 4:05 PM, Orest Halustchak
>>>>>>>> <orest.halustchak at autodesk.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please have a look at a new FDO RFC 50 that proposes to extend the FDO api
>>>>>>>>> to support the ability to use multiple classes in a select and in a filter.
>>>>>>>>> This would provide the ability the express joins at the fdo level.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://trac.osgeo.org/fdo/wiki/FDORfc50
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is a common capability that users need, the ability to join together two
>>>>>>>>> or more classes for a result to support analysis, rendering, or other uses.
>>>>>>>>> Until now, with FDO, this was done at a higher level such as the client-side
>>>>>>>>> join capabilities within MapGuide. While that capability is useful, it does
>>>>>>>>> not perform well and is error prone. This enhancement provides us a clear
>>>>>>>>> way to push that capability down to providers that support it such that they
>>>>>>>>> can translate the join into native server expressions. In general, I think
>>>>>>>>> it adds more power and flexibility to the FDO api.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As usual, this includes capability functions so that applications can
>>>>>>>>> discover if a provider supports this. We don't expect all providers to
>>>>>>>>> support this, mainly the ones that pass through fdo queries to sql.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I hope you like it. J
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks very much to Romy Dascalescu for putting this together and trying out
>>>>>>>>> various alternatives.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please provide your comments and suggestions.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Orest.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
> _______________________________________________
> 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