[hibernate-dev] MetadataSourceProcessor and associations

[Steve Ebersole]

** 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 at redhat.com
> <mailto:gbadner at 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 at gmail.com
>>> <mailto:steven.ebersole at gmail.com>>
>>> To: "Gail Badner" <gbadner at redhat.com <mailto:gbadner at redhat.com>>
>>> Cc: "Hibernate hibernate-dev" <hibernate-dev at lists.jboss.org
>>> <mailto:hibernate-dev at 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 at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at 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