Hi Arjan,
Thanks for the clarification. I see the point behind what you're
asking for, but I'm not (at least yet) convinced that this should be
pushed into a requirement on the provider in terms of the query
language processing.
Some further thoughts.... Looking at this from the DTO use case, a
further issue then becomes how much data to retrive in populating the
collection. I.e., suppose that someElements references another
entity, or that the collection is a one-to-many with a fetchType eager
to another collection etc. If we were to do the additional fetching,
it might not correspond to the use case that the DTO was to address.
On the other hand, if we were not to do the additional fetching, and
that data were needed, then either additional queries would need to be
run anyway or we'd need to add syntax into the select for pulling in
the additional state.
I'm open to persuasion as to whether this should be a new feature or
not, but at this point I think my own conclusion is that the
fetchGraph/copyGraph option would provide a better path.
best regards,
-Linda
On 1/9/14 7:21 AM, arjan tijms wrote:
> Hi Linda,
>
> On Wed, Jan 8, 2014 at 8:59 PM, Linda DeMichiel
> <linda.demichiel_at_oracle.com <mailto: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 <http://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?
>
>