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" <st...@hibernate.org>
To: "Max Rydahl Andersen" <max.ander...@redhat.com>
Cc: hibernate-dev@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 <st...@hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
