Steve and Strong,
Thanks for the clarification. This helped a lot.
I have a couple more questions inline below.
----- Original Message -----
From: "Steve Ebersole" <steven.ebersole(a)gmail.com>
To: "Strong Liu" <stliu(a)hibernate.org>
Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org>, "Gail
Sent: Friday, January 25, 2013 9:45:26 AM
Subject: Re: [hibernate-dev] MetadataSourceProcessor and associations
** DISCLAIMER : Its been a long time since I have been on the
branch, so please excuse any misuse of class/interface names...
On Thu 24 Jan 2013 11:21:22 PM CST, Strong Liu wrote:
> On Jan 24, 2013, at 1:26 PM, Gail Badner <gbadner(a)redhat.com
> <mailto:email@example.com>> wrote:
>> I am trying to figure out when we have all the necessary
>> to resolve everything required for associations.
>> IIUC, sources are processed in the following order by default:
>> 1) HBM sources extracted from MetadataSources passed to
>> 2) annotations sources extracted from MetadataSources passed to
>> MetadataImpl constructor;
>> 3) (annotations?) sources contributed by MetadataContributor
>> 4) HBM sources from JaxbRoot objects produced by
>> AdditionalJaxbRootProducer service.
(1) and (2) are really the same thing: metadata sources explicitly
handed to MetadataSources by the app (or contributed by any defined
MetadataSourcesContributor impls). Aka, these are the known hbm.xml
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?
(3) the intent of MetadataContributor is for integrations to be able
provide additional new information to the Metadata object. Part of
could be contributing "mappings", however, if it were to contribute
mappings it would be in the form of the new o.h.metamodel mapping
classes already. Technically it could alter existing bindings.
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?
(4) the intent of this, as Strong pointed out, is for Envers use
Basically it lets them read the already built Metamodel (fully
and pass us back additional JAXB mapings (hbm.xml) representing their
"version entities". To be completely honest, I always viewed this as
temporary hacky solution. IMO Envers should be producing full
EntityBinding graphs. But this was the path of least resistance to
Envers up and running on this branch as quickly as possible.
Ah, I think I get it. If Envers provided EntityBinding graphs (instead of JAXB mappings),
then Envers would contribute those bindings via the MetadataContributor service.
>> The same Binder is used create bindings from 1) and 2). A
>> Binder is used for 4).
TBH, I forget why different Binders were used.
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).
>> I am not familiar with how 3) and 4) are intended to be used.
>> Does 3) make "contributions" directly to the MetadataImpl? What
>> of contributions are they?
Answered above. Could technically contribute any of the things
on the MetadataImplentor contract.
>> Can 3) and 4) result in added or changed EntityBindings?
Well it would be odd for (4) to add (or change for that matter)
EntityBindings. (4) is all about creating additional "entity
but by way of contributing back new JAXB bindings to process. (3)
certainly add/change bindings.
> IIUC, 3) is for extensions that want to create / modify metamodel (
> binding / relational / domain ) directly
> 4) is for extensions what want to contribute hbm sources and let
> Binder to do the binding stuff
> take envers as an example, for each entity with @Audit, envers
> an internal entity and associate it with the original one.
> the current impl ( with old metamodel )
> 1. new Configuration -- mapping process
> 2. building SF
> 2.1 calling Integrator, which envers come into play, it just review
> all entities and find out the audit entities, then create hbm xml
> documents for each one, add these hbm documents into Configuration
> call the buildMappings again
> 2.2 SF cons process continues, this time, the persister factory
> sees the new Configuration processed mappings ( envers created hbm
> so, to achieve this in the new metamodel design, extensions can
> which way is easier :
> 1. the same way as envers currently does (creating hbm in memory
> ask hibernate to do the binding stuff) -- 4)
> 2. create/change metamodel directly -- 3)
>> ----- Original Message -----
>>> From: "Steve Ebersole" <steven.ebersole(a)gmail.com
>>> To: "Gail Badner" <gbadner(a)redhat.com
>>> Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org
>>> Sent: Wednesday, January 23, 2013 11:16:23 AM
>>> Subject: Re: [hibernate-dev] MetadataSourceProcessor and
>>> What you mention is in fact possible.
>>> And I have never been very hopeful about the "chasing"
>>> On Wed 23 Jan 2013 01:13:48 PM CST, Gail Badner wrote:
>>>> Is it possible for an entity containing one side of an
>>>> be mapped using annotations and the entity containing the
>>>> side of the association be mapped using an hbm mapping?
>>>> For example, suppose Order has annotations:
>>>> @OneToMany( mappedby="order" )
>>>> List<OrderLine> Order.orderLines
>>>> OrderLine is mapped using hbm.xml with:
>>>> <many-to-one name="order"/>
>>>> If annotations are processed first, then, IIUC, when
>>>> Order.orderLines is processed, the mapping for OrderLine won't
>>>> found (via chasing) because the
>>>> AnnotationMetadataSourceProcessorImpl does not have the source
>>>> the OrderLine mapping. As a result, the OrderLine EntityBinding
>>>> will not be able to be built until
>>>> is processed.
>>>> If so, this poses a fundamental problem with entity "chasing"
>>>> is implemented now, since the associated entity would not be
>>>> processed by the same MetadataSourceProcessor.
>>>> Am I missing something here?
>>>> hibernate-dev mailing list
>> hibernate-dev mailing list
> Best Regards,
> Strong Liu <stliu at hibernate.org