Emmanuel,
I would suggest "IS" rather than "INSTANCEOF".
However, doesn't this cause the problem that the expression "p.budget"
cannot be type-checked before actually executing the query. Do we want
JPA-QL to have to defer some type checking until query execution time?
> -----Original Message-----
> From: Emmanuel Bernard [mailto:emmanuel.bernard_at_jboss.com]
> Sent: Monday, 14 March 2011 11:00 a.m.
> To: linda.demichiel_at_oracle.com
> Cc: jsr338-experts_at_jpa-spec.java.net
> Subject: [jsr338-experts] Re: query improvements: downcasting
>
> Like some here, I am not a fan of TREAT as a method name.
>
> Why not try and explore the more OO approach of using instanceof:
> - it could be more flexible
> - it is clearer to OO people
> - w are not tied to the inconsistencies in DBs
> implementations of TREAT
>
> //notice the use of parenthesis
> WHERE ( INSTANCEOF(p, LargeProject) AND p.budget > 1000 )
> OR ( INSTANCEOF(p, SmallProject ) AND p.name
> LIKE "Persist%" )
> OR p.description LIKE "COST OVERRUN"
>
> //alternative syntax
> WHERE ( p INSTANCEOF LargeProject AND p.budget > 1000 )
> OR ( p INSTANCEOF SmallProject AND p.name
> LIKE "Persist%" )
> OR p.description LIKE "COST OVERRUN"
>
>
> On 11 mars 2011, at 21:23, Linda DeMichiel wrote:
>
> > Hi all,
> >
> > Outside of a few more minor aspects, it looks like we're on the same
> > page with regard to TREAT, so I'll start trying to spec it out more
> > formally.
> >
> > Here's where I think we are:
> >
> > 1) We'll support the use of TREAT for downcasting within path
> > expressions in the FROM and WHERE clauses.
> >
> > 2) If the target type is not a (proper or improper) subtype of
> > the static type of the first argument, the query is invalid (and
> > an exception is thrown).
> >
> > 3) If during query execution the first argument is not a (proper or
> > improper) subtype of the target type, we'll assume "null
> semantics"--
> > i.e. in the case of a join, the referenced object does not
> participate
> > in the result, and in the case of a restriction, the associated
> > predicate is false.
> >
> > 4) We'll add treat() to the criteria API
> >
> > BTW, I have a suspicion that trying to integrate this into the
> > spec will reveal a few more issues.
> >
> > If you disagree with the above, please speak now.
> >
> > thanks,
> >
> > -Linda
> >
> > p.s. I am still regarding the exact name as potentially subject to
> > change, but that is the easiest part to change later in the spec :-)
> >
> >
> > On 3/11/2011 8:51 AM, Matthew Adams wrote:
> >> On Fri, Mar 11, 2011 at 10:11 AM, Rainer Kwesi Schweigkoffer
> >> <kwesi_at_sap.com> wrote:
> >>> Matthew Adams, am 10 Mar 2011 hast Du um 17:12 zum Thema
> "[jsr338-experts] Re: query improvements: downcast" geschrieben :
> >>>
> >>>> If so, then I would restate **for the deferred,
> >>>> not-currently-specified projection use of TREAT AS**
> that if either
> >>>> Book is not assignment-compatible with Product or the
> filter results
> >>>> in type-incompatible instances with the projection expression, an
> >>>> exception is thrown.
> >>> Do you see a specific use case that would require to
> admit TREAT AS for
> >>> the select clause as well ?
> >>>
> >> I suppose not.
> >> Theoretically, using TREAT AS in the projection (the
> select clause) is
> >> not required. If the user wants to exclude certain types from the
> >> query, the mechanism by which I'd recommend that they do
> it would be
> >> to use FROM ... TREAT ... AS. To use SELECT ... TREAT ...
> AS requires
> >> that the filter only return objects of the expected type;
> if they want
> >> objects of that type, then why not just use FROM ... TREAT
> ... AS? It
> >> seems like they're just asking for an exception to be
> thrown if they
> >> use SELECT ... TREAT ... AS. The only behavior that
> they'd get with
> >> SELECT ... TREAT ... AS is either an exception if their query was
> >> wrong or the same behavior as FROM ... TREAT ... AS. Seems
> >> unnecessary to me.
> >> Let's see if anyone comes up with a use case for SELECT
> ... TREAT ...
> >> AS that can't be solved with a FROM ... TREAT ... AS. I'd be
> >> surprised if there were.
> >> -matthew
>
>
>