users@jpa-spec.java.net

[jpa-spec users] Re: Reason for limiting select clause to single-valued expression?

From: Kevin Sutter <sutter_at_us.ibm.com>
Date: Tue, 7 Jan 2014 15:05:10 -0600

Hi Arjan,
I don't recall the history of this restriction, but it's been there since
Day One of the JPA specification. Allowing collections to be selected
could simplify your scenario below, but it also opens other scenarios
which might not be as straight forward. For example, if we allowed
"SELECT o.lineItems...", would we also allow traversing this collection?
Something like "SELECT o.lineItems.id..."

Off the top of my head, I don't see why this restriction would have to
stay in place. I'd suggest opening a "feature request" and then it could
be evaluated when we start working on JPA 2.2 (or 3.0)...

----------------------------------------------------------------------------------------------------------------------------------------------------------------
-- Kevin Sutter

 

<arjan.tijms_at_gmail.com> wrote on 01/06/2014 05:25:00 PM:

> From: <arjan.tijms_at_gmail.com>
> To: users_at_jpa-spec.java.net,
> Date: 01/06/2014 05:30 PM
> Subject: [jpa-spec users] Reason for limiting select clause to
> single-valued expression?
>
> Hi,
>
> Section 4.8 of the JPA spec defines that a select expression is limited
> to a single valued path expression. This is emphasized in the body text
> of this section via the following paragraph:
>
> "Note that the SELECT clause must be specified to return only
> single-valued expressions. The query below is therefore not valid:
>
> SELECT o.lineItems FROM Order AS o"
>
> I wonder what the reason for this limitation is.
>
> In practice I found this to be quite a limitation when needing to
> create e.g. DTOs from an entity.
>
> The effect of selecting a single collection attribute from an entity
> can be mimicked by something like
>
> SELECT o.id, lineItem FROM Order AS o join o.lineItems as lineItem
>
> And then aggregating the result manually in Java code.
>
> If this can be done rather easily (but tediously) with manual code, why
> shouldn't the persistence provider be able to do this?
>