[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