[fdo-internals] New FDO RFC 50 posted - Extend FDO API to Select from Multiple Classes and Select Joins

Greg Boone greg.boone at autodesk.com
Wed Jun 16 11:22:27 EDT 2010


All this being said....

Where are we in agreement and what are the decision points left to resolve? 

Can we state what we all see as mandatory requirements to implement the RFC? I would like to update the document with these points and obtain sign off on them. We can then narrow down the possible discussion point. 

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Wednesday, June 16, 2010 11:15 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 do agree that "parent.fid = child.parent_id" then "fid = child.parent_id", would be easier to read, but I am not sure if it would be anymore work for the parse though... although it may prevent confusion.

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 9:55 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 got email back from admin that email with my answer was to big, so I
will  repeat it without previous emails.

Hi Orest,

For Alias part:

I made mistake in sample (not parent but parcel),
"sel->SetFeatureClassName(L"parent");"

As you suggested, we need to be able to define alias for class coming
into join to be able to support self join
And that alias is right now defined in join criteria itself as it is
suggested in original RFC :
"FdoPtr<FdoJoinCriteria> jc1 =
FdoJoinCriteria::Create(L"child",FdoIdentifier::Create(L"parcel"),
FdoJoinType_Inner, jfilter);"

I agree with you, eventually we would need only one alias even for self-join
but I think it is clearer to write join criteria as:
"parent.fid = child.parent_id" then "fid = child.parent_id".
In second case it is not so obvious that fid is coming from main class.
Beside it looks better for me, also I think it would be easier for
join criteria filter processor to handle such filter.

Because of that I suggested that we add ability to define additional
aliases into join criteria as needed and we are free to use it in both
ways.

Also, I would change FdoJoinCriteria so it is not necessary to define
new alias for join class in constructor.
FdoJoinCriteria would  have :
"joincriteria->SetFeatureClassName(L"parent");"
and add "AddAlias(alias,class)" function so aliases can be defined if
needed ( which depends on join filter ).


For properties part:
Yes, exactly. Properties to return would be combined from main list
and join criteria lists.

Haris
_______________________________________________
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