[hibernate-dev] MetadataSourceProcessor and associations
Gail Badner
gbadner at redhat.com
Fri Jan 25 14:42:10 EST 2013
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 at gmail.com>
> To: "Strong Liu" <stliu at hibernate.org>
> Cc: "Hibernate hibernate-dev" <hibernate-dev at lists.jboss.org>, "Gail Badner" <gbadner at redhat.com>
> 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 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.
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
> 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.
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
> 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.
>
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
> >> different
> >> 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.
> 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
>
More information about the hibernate-dev
mailing list