[hibernate-dev] Processing mapping information followup

[Steve Ebersole]

Nope.  Those should be Class references.

On 06/16/2011 12:39 PM, Gail Badner wrote:
> What about Class fields in the "binding" model?
>
> For example, EntityBinding has:
>
> 	private Class entityPersisterClass;
>
> Should this field really be a class name?
>
> ----- Original Message -----
> From: "Steve Ebersole"<steve at hibernate.org>
> To: "Max Rydahl Andersen"<max.andersen at redhat.com>
> Cc: hibernate-dev at 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 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 source information to metamodel works.
>>
>> jdbc sources is just for reverse engineering.
>>
>> If you are using the xml as your source that is the source for code generation that needs to be lazy.
>
> 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...
>
>>> We will strive to make sure nothing requires the domain classes to be present.  However, please not that in developing this new code I made a distinction.  Specifically, I believe this principal does *not* extend to types, identifier generators, etc.  Entity classes, component classes.. anything that is actually part of the domain model though we will strive to make not required to build this metadmodel.  You specifically asked about "model classes and types"; just wanted to highlight the difference in my mind.
>>
>> Yes, understood - custom types are required, just the call to .getReturnedClass() that should be avoided if .getReturnedClassName() or .getReturnedEntityName() can suffice ;)
>
> Again, I disagree with this use case.  Even going back and thinking
> through the case of enums.  Right now I totally see no benefit to making
> types non-resolvable in any form/fashion with regards to their typing
> information (jdbc and java).  So I plan on having type resolution to
> both JDBC type code(s) and java type (Class) be available.
>
>
>> i.e. a related "dream" of mine is that the metamodel is so decoupled that independent of the source of the mappings I can inject my own understanding
>> of entities - and provide the reflection without actually having classes, i.e. base it on the model eclipse JDT has about classes and make it possible to work
>> with non-compilable classes to be able to use hibernate core to validate the overall mappings.
>>
>
> org.hibernate.metamodel.Metadata is an interface.  You are free to build
> that in any way you see fit.  Today, the stuff contained within Metadata
> is not, though I am certainly open to such a discussion if you think it
> makes sense for your use cases.  This is THE reason I wanted your input
> and eyes on this design.  The earlier we address this stuff the better
> it would have been.
>
>
>

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