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

[Haris Kurtagic]

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).
2. There had to be some cons on proposed solution :)

3. SetFeatureClassName of FeatureCommand will be left unused and that
sounds like a bit confusing 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 ?
6. How we select which properties to be returned ? All properties from
all class names from GetFeatureClassNames by deafult ?
7. How we name properties to be returned (again alias/class name ?) ?
Same question for ordering properties ?

8. Why we have two ways for "Selecting from Multiple Classes" and
"Handling Joins" ? Could be same interface ?
9. I believe example in "Handling Joins" is missing implemented filter
"WHERE p.FeatId >= 0;"

I like sub-queries.

10. I don't like name of new expression type "ComputedClassIdentifier"
as it can be treated as property too
11. Why sub-query FdoISelect is not using standard SetFeatureClassName
in example ? It is non-join select.
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

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.
If application needs it, application will generate FDO class for it's
use ( it can be even utility in fdo itself).


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