Hi,
Thank you very much Steve for taking the time to review and comment on
this! What you propose perfectly fits my proposal.
Regards,
Guillermo González de Agüero.
On Fri, May 5, 2017 at 5:32 PM, Steve Ebersole <steve_at_hibernate.org> wrote:
> 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/@
>> 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.
>>>>>
>>>>