Hello Matthew,
> Uh, I *think* we're saying the same thing. Are we? Here's a
> restatement of what I think I'm saying.
>
> Using FROM ... JOIN TREAT ... AS is effectively a filter expression,
> which means that it would evaluate to true for those Order objects
> that have a product attribute that is assignment compatible with Book,
> and false where the Order's product is either null or not assignment
> compatible with Book. No ClassCastException should be thrown.
Yes, this is what I am suggesting.
--Gordon
Matthew Adams wrote:
> See below.
>
> On Thu, Mar 10, 2011 at 11:52 AM, Gordon Yorke <gordon.yorke_at_oracle.com> 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.
>>
>>
> Uh, I *think* we're saying the same thing. Are we? Here's a
> restatement of what I think I'm saying.
>
> Using FROM ... JOIN TREAT ... AS is effectively a filter expression,
> which means that it would evaluate to true for those Order objects
> that have a product attribute that is assignment compatible with Book,
> and false where the Order's product is either null or not assignment
> compatible with Book. No ClassCastException should be thrown.
>
> Please confirm, Gordon, that you are saying the same thing, or let me
> know if I'm still not being clear enough. If so, that would be
> somewhat of a rebuttal to those who are calling for a
> ClassCastException when TREAT AS is used, would it not? Those who are
> calling for a ClassCastException, please comment.
>
>
>> 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.
>>
>>
> I would be willing to defer that feature for now since we can add it
> later and vendors can support it as a nonstandard extension. However,
> if I were to specify its behavior, using TREAT AS in the projection
> should throw a ClassCastException if any objects passing the filter's
> conditions do not match their corresponding use in the projection, as
> per my second example.
>
>
>> --Gordon
>>
>> 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" ?
>>
>>
>>
>>
>>
>>
>
>
>
>