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