Re: [gentle-devel] Object Query Syntax

[Morten M. <mo...@me...>]

Hi Joe,

>>new Criteria( new QueryProperty("Date"), Operator.LessThan, new
>>QueryProperty(typeof(Supplier), "LastShipDate") );
>>    
>>
>You are assuming there is one and only one property or relationship on
>your object of the type Supplier.  If you have more than one, then you
>don't know what relationship or property you are referring to.
>  
>
So you'd always traverse the object graph for a match? How would you 
handle a cyclic reference or the case where two child objects both have 
a matching property?

I'd be inclined to think this has to be manually specified (to use the 
Employee case, force users to write "Employee.Manager.Name" when that is 
what they mean), but if you can work out something where this is not 
required I'll be impressed :)  We could opt for a "search and fail if 
match != 1 (not unique)", or go for a "closest match is used", which 
would probably cover a large part of the common scenarios.

I agree that this is a fair extension over the SqlQuery facility (i.e. 
expansion of such expressions into joins), and it also has me back on 
the track where I think ObjectQuery is qualified to exist. Thanks :)

>Since our ObjectQuery class models OQL it will look similar to our
>SqlQuery class that models SQL.  I actually do think we can re-use most
>of the classes that SqlQuery uses (e.g. Group, Or, And, etc...)
>  
>
That would be a time-saver, I think.

>But ObjectQuery will be quite different in that it needs to be aware of
>your object graph so it can look up what Order.Supplier.Name means and
>create the correct joins for you.
>  
>
I'm still in favor of considering the inheritance option - it will keep 
the client interface identical and offer us the greatest amount of 
reuse. However, if object queries are instantly "converted/expanded", it 
will not be possible to reconstruct the original query as entered by the 
user. Effectively, it would make the ObjectQuery class a stateless 
SqlQuery builder/factory (pros? cons?).

>If we did want to allow for OQL strings someday, I think it would still
>be helpful to have an object representation of the Query.  That way when
>we parse the OQL we can easily create the represented query.
>  
>
Agreed.

Yours,
Morten