[fdo-internals] RFC 50 updated (II)

[Orest Halustchak]

Hi,

Haris, did you have any more comments at this stage?

Also, this has been out for a discussion for a while and we haven't heard from too many others, so I'm assuming that everyone else is OK with where we're going with this.

We'd like to call for a vote fairly soon.

Thanks,
Orest.


-----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, July 13, 2010 8:58 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 50 updated (II)

Hi Haris,

I fixed:
 - point (1) I changed FdoSubSelectExpression from FdoExpression to FdoValueExpression
 - point (2) it was a comment which create confusion (since name of criteria cannot be null).
 - point (3) FdoJoinType_None - is the default value (same as NAN for double or None of enumeration in C#). It can be used in GetJoinTypes() to return no join supported. In this moment we can remove SupportsJoins() in case we want, since: SupportsJoins() = (GetJoinTypes() != 0); Using FdoJoinType_None in a join criteria will generate an exception

Thanks,
Romy.
________________________________________
From: Romica Dascalescu
Sent: Monday, July 12, 2010 2:56 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 50 updated (II)

Hi Haris,

Below are a few comments and answers:

1) I'm ok with this point.
2) I will fix the comment. I think I missed to remove the comment and it created confusion. Join criteria will have take an FDO identifier and name will never be NULL.
3) FdoJoinType_None can be used in two ways:
 - I can be used to avoid creating a join and implement a plain select e.g.: "select * from A, B WHERE C", however the implementation depends of the provider, since provider can create a SQL having a Join or not.
 - or none can be the not supported value. In C# each enumeration has a "default" value and after that all other valid values, I would say is like NAN for doubles.
I like first option but I'm OK with the second one also.

4) I still think we should keep aliases simple and not try to complicate things and allow provider and user to have more options. Aliases should be supported in the simplest way and filter should not be over checked as it is now and it should allow combinations which FDO might not be able to support but SQL support them. I still think we should keep alias for the main class in the select command and join criteria and parse the filter by pushing this identifier into the filter processor.

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: Friday, June 25, 2010 6:43 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC 50 updated (II)

sorry, I somehow managed to send email too early while typing body of it

to continue on point 4)

In one of samples we have in previous conversation we had self-join with
 parent.id = child.id where parent and child are aliases. I think that
both "parent" and "child"  has to be defined on level of join criteria
as aliases of "parcel" class.
Could be even more important now when we can have filter for
join-criteria with sub-select , which again can have join criteria in
it.

Haris

On Fri, Jun 25, 2010 at 12:36 PM, Haris Kurtagic <haris at sl-king.com> wrote:
> Hi Romy,
>
> First of all, thanks for effort in discussing and changing this RFC.
>
> I have few suggestions/questions:
>
> 1) To change FdoSubSelectExpression from FdoExpression to FdoValueExpression
>    It would allow  use of FdoSubSelectExpression in inserts and
> updates as well.
>
>
> 2) FdoJoinCriteriaCollection has functions
>   /// Returns FdoJoinCriteria having the name or NULL.
>          FDO_API FdoJoinCriteria* FindItem(FdoString* name) and
> FDO_API FdoJoinCriteria* GeiItem(FdoString* name)
>
>    Parameter name is to search over join criteria alias or class name or both ?
>    Change name and description of function to be clear what it is ?
>
> 3) What is supposed to be FdoJoinType_None ? implicit join (where) ?
>
> 4) I think I can see problems in join filter implementations.
>    I think it is important that when join criteria is used and class
> aliases are used in filter that those aliases are clearly defined in
> join criteria.
>   Otherwise I believe we will run into difficult and non-consistent
> implementations across providers.
>
>
>   In one of samples we have in previous conversation we had self-join with
>   parent.id = child.id where parent and child are aliases
>
>
> Haris
>
> On Thu, Jun 24, 2010 at 9:29 PM, Romica Dascalescu
> <Romica.Dascalescu at autodesk.com> wrote:
>> Hi,
>>
>> RFC 50 (http://trac.osgeo.org/fdo/wiki/FDORfc50) has been updated to include all comments received and is now ready for review.
>> Added a new capability: SupportsSubSelects() in order to allow applications to detect if a connection supports sub-selects in filters.
>>
>> Please review and provide additional feedback.
>>
>> Thanks,
>> Romy.
>>
>> _______________________________________________
>> 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