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 <st...@hibernate.org> wrote: > On Fri, Aug 18, 2017 at 10:21 AM Arnold Gálovics <galovicsarn...@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... > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
