From: "Steve Ebersole" <steven.ebersole(a)gmail.com&gt; To: "Strong Liu" <stliu(a)hibernate.org&gt; Cc: "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt;, "Gail Badner" <gbadner(a)redhat.com&gt; 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 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