>> 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

Reply via email to