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
llections? Would they be included in 4 (attributes)?
>
> - Original Message -
> From: "Steve Ebersole"
> To: hibernate-dev@lists.jboss.org
> Sent: Monday, June 13, 2011 2:29:41 PM
> Subject: [hibernate-dev] Processing mapping information followup
>
> Wanted
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
: "Steve Ebersole"
To: hibernate-dev@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
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 le
13 matches
Mail list logo
