[hibernate-dev] MetadataSourceProcessor and associations

Steve Ebersole steve at hibernate.org
Fri Jan 25 18:46:30 EST 2013


> Can we assume that, after 1) and 2) execute, all information (in the form of hbm/annotations source) is available to resolve all existing associations?
>
> If anything is left unresolved, should it be an exception?
I think it is reasonable to make that a rule.

>
> Can we assume that after 3) is executed that all new and pre-existing (from 1) and 2)) associations in the metadata are (still) resolved? If so, should there be a check to ensure this is true?
Again, I'd say this is reasonable.  However, I'd caution against running 
such checks after (1) and (2) and then after (3) again.  I'd run the 
checks just once, after (3).


> Are Envers bindings completely unrelated (in terms of 
> subclasses/superclasses) and unassociated (in terms of 
> one-to-one/many-to-one/one-to-many/many-to-many associations) with 
> entity bindings produced by 1), 2), and 3)? If unrelated and 
> unassociated with mappings provided by 1) and 2), then it makes sense 
> that a separate Binder be used for 4). 
The best way to think of Envers bindings is as complete shadows of the 
main application bindings.  For example, for a forum application that 
defined User and Message entities, Envers would create complete shadows 
of that model *including associations*; so it would have User_ver and 
Message_ver.   Supposing the original model defined Message.user as an 
association, the Envers shadow model would have the "same" except that 
Message_ver.user would point to User_ver (not User).

And for completeness, yes, for inheritance, same thing...

Not sure that describes the need for a separate Binder instance to be 
used though.  But, like I said, I forget why I did (had to do?) that.



More information about the hibernate-dev mailing list