users@jpa-spec.java.net

[jpa-spec users] Re: Specify that AttributeConverter's must work on native queries

From: Steve Ebersole <steve_at_hibernate.org>
Date: Fri, 05 May 2017 15:32:06 +0000

To clarify...

Section *3.10.16.1 Returning Managed Entities from Native Queries* does
discuss this topic. But, all it says in regards to your *exact case* is:

<quote>
In the simplest case—i.e., when the results of the query are limited to
entities of a single entity class and
the mapping information can be derived from the columns of the SQL result
and the object/relational
mapping metadata—it is sufficient to specify only the expected class of the
entity result.
</quote>

So I guess if that rather large caveat in there is met, then we should also
apply the converter *assuming we agree to require applying the converter in
the @SqlResultSetMapping case*. Those 2 should be handled the same I guess.



On Fri, May 5, 2017 at 10:18 AM Steve Ebersole <steve_at_hibernate.org> wrote:

> TBH I have yet to find anything in the spec that says what should happen
> when an entity Class is given as a native query's resultClass. It is
> *very* different situation from explicitly mapping the result set using
> @SqlResultSetMapping/_at_EntityResult. Personally I'd say that the behavior
> of creating a native query with an entity resultClass is undefined.
>
> The reason this distinction is important is that because @EntityResult
> defines an explicit mapping from the ResultSet values to the entity
> attributes we'd know when to apply the converters. Getting this to work by
> just specifying the entity Class as the resultClass would mean that JPA
> would have to require the low-level "how's" regarding how a provider
> manifest an entity from a ResultSet. By names? Ok, what names? By
> order? Ok, what order? We'd need this to be able to make the native SQL
> portable *across providers*. I think that is a bad thing. And we already
> have a way to DoTheRightThing(tm) via JPA...
> @SqlResultSetMapping/_at_EntityResult.
>
> So again, I can see adding this in regards to
> @SqlResultSetMapping/_at_EntityResult, but -1 to doing it for entity
> resultClass. In fact as I mentioned above, I'd even suggest that we
> clarify this in the spec: "Support for naming an entity class via the
> resultClass element is undefined."
>
> On Thu, May 4, 2017 at 11:22 AM Guillermo González de Agüero <
> z06.guillermo_at_gmail.com> wrote:
>
>> Hi,
>>
>> My problem is always using entities. JPQL allows me to use attribute
>> types that just don't work then I have to revert to a native query.
>>
>> My case was using @NamedNativeQueries with en entity resultClass. I can
>> think of the following two cases:
>> - @NamedNativeQuery with a resultClass, or called with an entity resul at
>> runtime
>> - em.createNativeQuery specifying an entity class or a named entity
>> result.
>>
>> Other cases where a DTO is created can be easily handled by the end user
>> without much polluting of the domain model.
>>
>> Would you be ok with that approach?
>>
>>
>> Regards,
>>
>> Guillermo González de Agüero
>>
>> El jue., 4 de mayo de 2017 17:19, Steve Ebersole <steve_at_hibernate.org>
>> escribió:
>>
>>> If we are limiting this alteration to *just* cases where there is an
>>> "@EntityResult" associated with that particular query result, then I guess
>>> I could see this. But I'd be very opposed to forcing implementors to do
>>> this for all other cases.
>>>
>>> On Thu, May 4, 2017 at 7:01 AM Guillermo González de Agüero <
>>> z06.guillermo_at_gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> AttributeConverter's are one of my favourite JPA 2.1 features, but
>>>> unfortunately, the spec only mandates them to work on JPQL queries and
>>>> Criteria queries. Its behaviour on native queries is unspecified (point 3.9
>>>> of the spec):
>>>>
>>>> *"[...] The persistence provider must apply any conversion methods to
>>>> instances of attribute values in path expressions used within Java
>>>> Persistence query language queries or criteria queries (such as in
>>>> comparisons, bulk updates, etc.) before sending them to the database for
>>>> the query execution. [...] If the result of a Java Persistence query
>>>> language query or criteria query includes one or more entity attributes for
>>>> which conversion mappings have been specified, the persistence provider
>>>> must apply the specified conversions to the corresponding values in the
>>>> query result before returning them to the application. [...]"*
>>>>
>>>> As a user, I expect them to also work on native queries, and
>>>> EclipseLink already does that. However, it doesn't work on Hibernate, and
>>>> the spec doesn't force it to work. This drastically reduces the
>>>> possibilities of this feature, as they can only be used on entities where
>>>> no native queries are involved.
>>>>
>>>> I propose to rephrase point 3.9 in order to account for native queries
>>>> in addition to JPQL and Criteria ones. Was it an intended omission on 2.1
>>>> or did it just wend unnoticed?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Guillermo González de Agüero.
>>>>
>>>