On 06/17/2011 06:44 AM, Max Rydahl Andersen wrote:
>>> Any git branches/forks where Configuration is removed or a test is present
>>> that doesn't use the "old " Configuration approach and i'll try and take a
>>> new look.
>>
>> There are some tests in master
>
>
> Could you be a tad more specifi
>> Any git branches/forks where Configuration is removed or a test is present
>> that doesn't use the "old " Configuration approach and i'll try and take a
>> new look.
>
> There are some tests in master
Could you be a tad more specific ? Package or even a class name to narrow it
down :)
/ma
>> Again non resolution of the domain classes is already handled. Or should
>> be. That has been a consistent mantra as we have developed this new
>> metamodel code. As for types...
>
> Okey - is Components covered by this ?
Components are domain classes, so yes they would fall under what we
ame?
>
> - Original Message -
> From: "Steve Ebersole"
> To: "Max Rydahl Andersen"
> Cc: hibernate-dev@lists.jboss.org
> Sent: Thursday, June 16, 2011 8:02:54 AM
> Subject: Re: [hibernate-dev] Processing mapping information followup
>
>>> In th
lists.jboss.org
Sent: Thursday, June 16, 2011 8:02:54 AM
Subject: Re: [hibernate-dev] Processing mapping information followup
>> In the new terminology, what we are discussing is the process for handling
>> "metadata sources" (o.h.metamodel.source). What you describe is rea
>>> In the new terminology, what we are discussing is the process for handling
>>> "metadata sources" (o.h.metamodel.source). What you describe is really a
>>> parallel source (o.h.metamodel.source.jdbc???). So it is going to be
>>> completely up to the developer of that code how the binding o
>> In the new terminology, what we are discussing is the process for handling
>> "metadata sources" (o.h.metamodel.source). What you describe is really a
>> parallel source (o.h.metamodel.source.jdbc???). So it is going to be
>> completely up to the developer of that code how the binding of so
> What I am discussing here has no effect on this concern.
>
> In the new terminology, what we are discussing is the process for handling
> "metadata sources" (o.h.metamodel.source). What you describe is really a
> parallel source (o.h.metamodel.source.jdbc???). So it is going to be
> complet
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).
itself poses a problem. It can co
What I am discussing here has no effect on this concern.
In the new terminology, what we are discussing is the process for
handling "metadata sources" (o.h.metamodel.source). What you describe
is really a parallel source (o.h.metamodel.source.jdbc???). So it is
going to be completely up to th
Any idea how much this would affect tools ability to reflect on the metamodel
without requiring the actual
model classes and types to be available ?
At what time will the classes/types be *required* to be available?
i.e. for H3 as long as we filled out all the type info in the xml hibernate did
Components and properties (as in ) 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:
12 matches
Mail list logo
