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