Hi Linda,
On Wed, Jan 8, 2014 at 8:59 PM, Linda DeMichiel
<linda.demichiel_at_oracle.com>wrote:
> 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
example:
@Entity
public class MyEntity {
@Id
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":
SELECT
new com.example.MyDTO(
_myEntity.value,
_myEntity.someElements
)
FROM
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,
Arjan
>
>
>
> 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?
>>
>>