[hibernate-dev] DTO Projection support for native queries?

[Arnold Gálovics]

Hey Steve,

Sorry for the late response.

I agree with you. It's always better to have a compile time error than a
runtime one. However, there are still projects out there which are
prohibited to use the native Hibernate API "just because" some architect
says it is not a good thing to do.

This is rather just an idea from me because personally I worked on this
kind of project in the past and I could've really make use of such a
feature.

I'd be interested in other opinions as well.

Best Regards,
Arnold

On Fri, Aug 18, 2017 at 5:53 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Aug 18, 2017 at 10:21 AM Arnold Gálovics <galovicsarnold at gmail.com>
> wrote:
>
>> Hey Steve,
>>
>> Thanks for the answer.
>>
>> I was aware of these two solutions but there are definitely projects
>> which want to use DTO projections and cannot (don't) want to utilize
>> neither the annotation nor the native Hibernate API.
>>
>> I think using the approach I mentioned would be beneficial, at least I
>> see the potential.
>>
>> Do you think if we implement this it would violate some contract or do
>> you see anything which prevents us from supporting this?
>>
>
> It's not a question of whether we *can* do this.  Its programming...
> essentially anything is possible.  Its a question of whether it makes
> sense.  And I personally am not sure this does conceptually, although I
> will for sure listen to other opinions.
>
> At the very least however I am not even going to consider this in 5.x
>
> And btw... you say you do not want to use the native Hibernate APIs yet
> you want to use some Hibernate-specific feature beyond the spec.  Assuming
> the desire to not use the Hibernate APIs is to allow for that completely
> pie-in-the-sky idea of provider portability adding this feature actually
> introduces a unequivocally worse situation.  At least when you use the
> Hibernate-specific APIs you will get a compile-time error when you switch
> vendors; but using this proposed feature you'd only get such a error at
> runtime - and you'd still have the problem of how to solve this in the new
> provider...
>
>