jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: query improvements: downcasting

From: Matthew Adams <matthew_at_matthewadams.me>
Date: Thu, 10 Mar 2011 16:20:57 -0600

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" ?
>
>
>
>
>



-- 
mailto:matthew_at_matthewadams.me
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12_at_gmail.com
msn:matthew_at_matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams