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

Mon Jun 7 18:44:11 EDT 2010

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.

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

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

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.

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"

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.

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

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.

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
>
>
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals