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

From: arjan tijms <>
Date: Thu, 9 Jan 2014 16:21:46 +0100

Hi Linda,

On Wed, Jan 8, 2014 at 8:59 PM, Linda DeMichiel

> In the above example, were you expecting the query result to be a
> singleResult or a resultList?

A single result really, where the single result is of whatever type the
selected attribute had (e.g. Set, List, etc). The idea is to simply make a
sub-selection from the entity's attributes. As a somewhat more elaborate

public class MyEntity {

    Long id;

    String value;

    @ElementCollection(fetch = EAGER)
    List<String> someElements;

    @ElementCollection(fetch = EAGER)
    List<String> someMoreElements;

    // More attributes below ...

Now I'd like to have a DTO which consists of just the attributes "value"
and "someElements":

    new com.example.MyDTO(
    MyEntity _myEntity

The restriction was made for conformance to "standard" SQL,
> which doesn't support collection-valued results in the select list.

I see, but isn't the result from a JPQL query on the OO side of things
where such limitations aren't conceptually necessary?

If a JPQL query can return a MyEntity which has a MyEntity.value and
MyEntity.someElements among others, then intuitively you'd say it should
also be able to return a MyDTO with a MyDTO.value and MyDTO.someElements,
wouldn't you?

> BTW, I had hoped to address the DTO creation issue with the
> copy-graph proposal, but unfortunately we ran out of bandwidth to
> reach consensus on that in JPA 2.1

I think that would indeed have been a very nice alternative.

Kind regards,

> The effect of selecting a single collection attribute from an entity
>> can be mimicked by something like
>> SELECT, 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?