Whatever, @MapKey(ManyToMany) are actually already mixing content, I'm
gonna go your path.
Emmanuel Bernard wrote:
I agree with your analysis, but @MapKeyTarget vs @o.h.a.MapKey /
@o.h.a.MapKeyManyToMany enhancement with target is not influenced by
the @j.p.MapKey design flaws.
Pros of each
I agree with your analysis, but @MapKeyTarget vs @o.h.a.MapKey /
@o.h.a.MapKeyManyToMany enhancement with target is not influenced by the
@j.p.MapKey design flaws.
Pros of each solution are
1. @MapKeyTarget
SoC (Relational descriptions are split from Object descriptions in
annotations)
@Targe
this would help on a related issue
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2268 which
is about the problem of redundant methods in jdk5 when you have covariant
methods (e.g. Object clone() in Object and Customer clone() in Customer)
With respect to HHH-2268 we could al
On Nov 29, 2006, at 9:23 PM, Emmanuel Bernard wrote:
Note that I hope the future spec will hopefully handle all cases
nicely (ie add a targetElement in @Embedded), @MapKey should go to
back the drawing board from a spec POV so we can think of something
clean from the begining.
I'm for 2.
I'm looking at ANN-422
In HA, the target is usually inferred from the API (generics), and can
be overridden in all associations through targetEntity (
@ManyToOne(targetEntity...) )
currently, you cannot override the target for a component, nor you can
override it for a
Two solutions
1.
Def
