** DISCLAIMER : Its been a long time since I have been on the metamodel
branch, so please excuse any misuse of class/interface names...
Comments inline...
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:gbadner@redhat.com>> wrote:
>
> I am trying to figure out when we have all the necessary information
> to resolve everything required for associations.
>
> IIUC, sources are processed in the following order by default:
>
> 1) HBM sources extracted from MetadataSources passed to MetadataImpl
> constructor;
> 2) annotations sources extracted from MetadataSources passed to
> MetadataImpl constructor;
> 3) (annotations?) sources contributed by MetadataContributor service;
> 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 and
annotation sources.
(3) the intent of MetadataContributor is for integrations to be able to
provide additional new information to the Metadata object. Part of that
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.
(4) the intent of this, as Strong pointed out, is for Envers use case.
Basically it lets them read the already built Metamodel (fully resolved)
and pass us back additional JAXB mapings (hbm.xml) representing their
"version entities". To be completely honest, I always viewed this as a
temporary hacky solution. IMO Envers should be producing full
EntityBinding graphs. But this was the path of least resistance to get
Envers up and running on this branch as quickly as possible.
> The same Binder is used create bindings from 1) and 2). A
different
> Binder is used for 4).
TBH, I forget why different Binders were used.
> I am not familiar with how 3) and 4) are intended to be used.
Answered above
>
> Does 3) make "contributions" directly to the MetadataImpl? What kind
> of contributions are they?
Answered above. Could technically contribute any of
the things exposed
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 bindings"
but by way of contributing back new JAXB bindings to process. (3) Could
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 the
Binder to do the binding stuff
take envers as an example, for each entity with @Audit, envers creates
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 and
call the buildMappings again
2.2 SF cons process continues, this time, the persister factory
sees the new Configuration processed mappings ( envers created hbm
included)
so, to achieve this in the new metamodel design, extensions can choose
which way is easier :
1. the same way as envers currently does (creating hbm in memory and
ask hibernate to do the binding stuff) -- 4)
2. create/change metamodel directly -- 3)
>
>
> Regards,
> Gail
>
> ----- Original Message -----
>>
>> From: "Steve Ebersole" <steven.ebersole(a)gmail.com
>> <mailto:steven.ebersole@gmail.com>>
>> To: "Gail Badner" <gbadner(a)redhat.com
<mailto:gbadner@redhat.com>>
>> Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org
>> <mailto:hibernate-dev@lists.jboss.org>>
>> Sent: Wednesday, January 23, 2013 11:16:23 AM
>> Subject: Re: [hibernate-dev] MetadataSourceProcessor and associations
>>
>> What you mention is in fact possible.
>>
>> And I have never been very hopeful about the "chasing" approach...
>>
>>
>> On Wed 23 Jan 2013 01:13:48 PM CST, Gail Badner wrote:
>>>
>>> Is it possible for an entity containing one side of an association
>>> be mapped using annotations and the entity containing the opposite
>>> 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 be
>>> found (via chasing) because the
>>> AnnotationMetadataSourceProcessorImpl does not have the source for
>>> the OrderLine mapping. As a result, the OrderLine EntityBinding
>>> will not be able to be built until HbmMetadataSourceProcessorImpl
>>> is processed.
>>>
>>> If so, this poses a fundamental problem with entity "chasing" as
it
>>> is implemented now, since the associated entity would not be
>>> processed by the same MetadataSourceProcessor.
>>>
>>> Am I missing something here?
>>>
>>> Thanks,
>>> Gail
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------------------
Best Regards,
Strong Liu <stliu at
hibernate.org <
http://hibernate.org/>>
http://about.me/stliu/bio