>>> 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...
Okey - is Components covered by this ? Those are also code generated, or at least is for H3. As I recall Components were modelled by the same mechanism that UserTypes uses. >>> 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. Ok - I guess we'll just have to wait and see. >> 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. The usecase I was thinking of is so I can delegate the class metadata and construction of instances. I actually think H3 had most of this, except it wasn't easy to override the defaults globally and thus you had to thoroughly massage the model to make it happen - leaving behind the biggest issue, that classloading of entities/types were not bound by a sessionfactory so you ended up having class cast problems when running in Eclipse/osgi. > 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. As far as I know I already given this feedback multiple times. Unfortunately I don't have time to attempt to migrate hibernate tools usecases. We are trying to do that now but awaiting actual code that we can try it against. 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. /max http://about.me/maxandersen _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
