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

[Steve Ebersole]

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