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