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(a)hibernate.org
http://hibernate.org