[hibernate-dev] Processing mapping information followup

[Steve Ebersole]

That is a great point about components.  Thinking components should 
really be handled just like we propose for entities.  Especially if we 
allow inheritance hierarchies with components (which I would love to do 
generally and to account for here specifically).

<properties/> itself poses a problem.  It can contain associations, but 
can also be the basis for defining an association.  In this respect they 
are just like components.  So maybe we need to handle them then same as 
we do for components.

Collections are associations, and would just be handled in that phase 
whatever their collection type or element type.

On 06/13/2011 07:02 PM, Gail Badner wrote:
> Components and properties (as in<properties>) can have embedded to-one associations.
>
> Would these be processed during 4 (attribute), with any embedded associations deferred until 5 (associations)?
>
> What about value collections? Would they be included in 4 (attributes)?
>
> ----- Original Message -----
> From: "Steve Ebersole"<steve at hibernate.org>
> To: hibernate-dev at lists.jboss.org
> Sent: Monday, June 13, 2011 2:29:41 PM
> Subject: [hibernate-dev] Processing mapping information followup
>
> Wanted to start a follow up discussion to the conversation we had at the
> IRC meeting on 6/13 with regards to changing the way we process mapping
> information to follow dependencies in the various types of information.
>
> What we do currently (in the metamodel code) is essentially the same as
> the legacy code.  That is to say we process through a mapping source in
> full and then move on to the next one, saving off "second passes"
> whenever we encounter information on which we have to wait.  The second
> passes in the new metamodel code are isolated I guess (so far) to
> org.hibernate.metamodel.source.internal.EntityReferenceResolver
>
> What I proposed instead is quite different, more like what I did for the
> rest of the MetadataImpl constructor code in terms of defining
> dependencies and processing stuff in an order that makes sure to avoid
> the need for second passes.
>
> Here is the initial swab at the levels of information:
> 1) entity - basic entity information such as name, hierarchy
> 2) identifiers - normal identifiers could almost be handled in the first
> level.  key-many-to-one still needs some form of delayed queuing.
> 3) secondary tables
> 4) attributes
> 5) associations
>
> The dependencies flow downward; (2) depends on (1); (3) depends on (2); etc.
>
> I liked handling (3) secondary tables separately because they basically
> expand the possible set of columns available for (4) and (5).
>

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org