[hibernate-dev] Fwd: Re: Proxies and typing

[Steve Ebersole]

Just to bring this back up one more time :)

I plan on going this route in Hibernate 5.  Specifically the part where 
using @Proxy with proxyClass as an interface registers the entity under 
that interface name rather than the under the class name.  This gives 
us the ability to expose parameterized types on our APIs which is a big 
win.  We can investigate different approaches for annotating interfaces 
as we have time.

On Wed 21 Mar 2012 08:55:40 AM CDT, Steve Ebersole wrote:
> Oops, forgot the name of the test package I referred to :)
>
> org.hibernate.test.dynamicentity
>
> On Wed 21 Mar 2012 08:06:44 AM CDT, Steve Ebersole wrote:
>> Comments inline...
>>
>>
>> On Wed 21 Mar 2012 05:36:01 AM CDT, Sanne Grinovero wrote:
>>> As an API user if I'm expected to use the _User_ interface, I think I
>>> would expect the annotations to be defined on the interface, not on
>>> the UserImpl.class .. as with the rest of mapping annotations.
>>>
>>> I don't know about the technical requirements to make this
>>> implementable; I guess you need some UserImpl class as a prototype?
>>>
>>> If so wouldn't it make sense to have
>>>
>>> @Entity @PrototypedBy(UserImpl.class)
>>> public interface User {
>>>
>>> @Id Long getUserId();
>>> void setUserId(Long id);
>>>
>>> }
>>>
>>> public class UserImpl implements User {
>>> ...
>>> }
>>
>> I'm ok with this. I do not like the phrase "prototyped by", but the
>> general idea is good. In fact this was my proposal initially on how
>> to map this situation :)
>>
>> However, I want to at least allow both ways to map it. Couple of
>> reasons. First (brought up on the JPA list in regards to this
>> proposal) is that you now have a bi-directional relationship between
>> the interface and implementation. Why is that important? The
>> reasoning on the JPA list was just the unnaturalness of the
>> bi-directionality and being able to split each into jars (thinking
>> osgi). Another thought I had was imagine you are trying to persist
>> interfaces provided to you by another group/project.
>>
>>
>>> And ideally I would expect the "prototype" class to be not needed /
>>> optional.
>>
>> Yes we spoke of this before also. I agree the interface should be
>> enough. And as I pointed out to you, nothing in Hibernate internals
>> disallows this. We have quite a few tests (see the ... test package)
>> making sure that persisting interfaces works using proxies and
>> various approaches. But here is rub... If Hibernate is the one
>> generating the proxies, how is the application supposed to
>> instantiate instances of the entity? I don't have a clean answer to
>> that at the moment.
>>
>>
>>> Finally, since I'd expect the setter / getter implementations in the
>>> proxy to be generated by us, could we have them take care of
>>> bi-directional relations, to update both sides of relation
>>> automatically and correctly? I was speaking recently to a Ruby
>>> developer who just switched to JavaEE, and he pointed out that this
>>> requirement is long gone in other persistence APIs.
>>> I know by experience this also frequently bites beginners, and even
>>> experienced developers have to write code about this.. this looks like
>>> a chance to evolve?
>>
>> You don't need proxies to do this. In fact unless things have changed
>> drastically, most other providers actually use bytecode manip (build
>> time or via agent) rather than proxying. Ideally, if we are going to
>> offer this "evolution", I'd prefer that it be more consistent,
>> meaning that it would be nice if it was not only available to those
>> mapping interfaces. We do have a long-standing task to investigate
>> java agents for in-VM enhancement, though a major pre-req there is
>> actually getting some decent enhancement code. Our current
>> enhancement code is pretty lacking.
>>
>

--
steve at hibernate.org
http://hibernate.org