jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: query improvements: downcasting

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Tue, 08 Mar 2011 15:52:53 -0800

On 3/8/2011 11:51 AM, Emmanuel Bernard wrote:
> On 7 mars 2011, at 21:45, Linda DeMichiel wrote:
>
>> SELECT e FROM Employee JOIN e.projects p
>> WHERE TREAT(p AS LargeProject).budget > 1000 OR
>> TREAT(p AS SmallProject).name LIKE "Persist%" OR
>> p.description LIKE "COST OVERRUN"
>
> This is really the use case that makes the most sense to me as the other use cases Linda has shown seem to overlap with TYPE.
>

I'm afraid I don't understand. TYPE doesn't do downcasting.

> but that leads to some questions:
> 1. if both LargeProject and SmallProject have a budget property, do we return all Projects.budget > 1000? Or is the query more like
> SELECT e FROM Employee JOIN e.projects p
> WHERE ( TYPE(p) = LargeProject AND p.budget > 1000) OR
> (TYPE(p) = SmallProject AND p.name LIKE "Persist%" ) OR
> p.description LIKE "COST OVERRUN"
>
> For reference the idiom in Java is
> (p instanceof LargeProject && ( (LargeProject) p).projects > 1000) ||
> (p instanceof SmallProject && isLike( ((SmallProject) p).name, "Persist%" ) ) ||
> isLike(p.description, "COST OVERRUN") //evaluates to true all the time?
>

yes

> And assuming javac was smarter we could do
>
> (p instanceof LargeProject) && p.projects > 1000) ||
> (p instanceof SmallProject) && isLike( p.name, "Persist%" ) ||
> isLike(p.description, "COST OVERRUN")
>
> 2. if LargeProject does not have a budget property, what happens?
>

Exception, because the query is ill-formed. I.e., it is treated the same as
p.description would be treated if Project didn't have a description attribute.

>