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.