On 3/10/2011 9:52 AM, Gordon Yorke wrote:
> The initial premise that "JOIN TREAT(o.product AS Book) b" would fail is
> incorrect. The behaviour of this JOIN TREAT AS clause should be to JOIN
> to "o.product" Books. Or in other words return rows for Order where
> ".product" is a book. Not all ".products" have to be books but any
> orders that do not have books would be eliminated from the result.
>
> There is no need to allow TREAT in the select clause. TREAT in the
> select clause would have to return null instead of evaluating to false
> because in the selection it would have to be a function and not a
> filter. If it is a function then users would always have to filter the
> results in the other clauses anyway or be stuck trying to distinguish
> between a null "product" and a result that had no "product" attribute.
>
> It is best to leave TREAT out of the select clause for now. If there is
> a strong demand then we can consider adding it in a future version.
> --Gordon
>
I am fine with this restriction, and the reason I didn't illustrate the
use of TREAT in the SELECT clause is the potential confusion due to
the ambiguity of nulls in the result if they weren't otherwise filtered out.
If we do get demand for TREAT in the SELECT, it is something that can be
added at a later point.
-Linda
> Matthew Adams wrote:
>> Wait a second, here. It just occurred to me that downcasting could be
>> used as part of the filter expression and/or as part of the projection
>> expression.
>>
>> Quick terminological review:
>> Projection == the shape of the results (the "select" part)
>> Filter == the conditions the data must satisfy (the "where" part)
>> Fetch plan == the breadth & depth of the objects that are returned in
>> the project (not defined in JPA yet)
>>
>> Now, take Linda's first example:
>>
>> SELECT b.name, b.ISBN
>> FROM Order o JOIN TREAT(o.product AS Book) b
>>
>> This query would obviously fail all of the time, unless all orders had
>> a product that was of type Book. It's clear to me in this example
>> that the downcast is being used to filter results. In this case,
>> there should be no ClassCastException thrown -- the expression should
>> be considered as returning a false in the condition. It's like a
>> WHERE without the WHERE.
>>
>> Now, let's modify it a bit and use it only in the projection of the query:
>>
>> SELECT TREAT(o.product AS Book).ISBN
>> FROM Order o JOIN o.product
>> WHERE ...
>>
>> The ellipsis ("...") in the filter would be some set of conditions
>> that should only cause the return of orders with products of type
>> Book. In this case, if some orders with products not of type Book
>> were returned, the user's expectation was certainly not met and a
>> ClassCastException should be thrown.
>>
>> I think that there are two uses/contexts for the use of downcasting
>> here that we were not separating thus far in the discussion.
>> Thoughts?
>>
>> -matthew
>>
>>
>> On Thu, Mar 10, 2011 at 9:37 AM, Emmanuel Bernard
>> <emmanuel.bernard_at_jboss.com> wrote:
>>
>>> no that was a copy/paste error.
>>>
>>> On 8 mars 2011, at 21:34, Werner Keil wrote:
>>>
>>>
>>>> @Emanuel, was there a reason why you changed your Java example to: "p.projects > 1000" not "p.budget > 1000" ?
>>>>
>>>
>>
>>
>>
>>