Components and properties (as in<properties>) can have embedded to-one associations. Would these be processed during 4 (attribute), with any embedded associations deferred until 5 (associations)? What about value collections? Would they be included in 4 (attributes)? ----- Original Message ----- From: "Steve Ebersole&quot;&lt;steve(a)hibernate.org&gt; To: hibernate-dev(a)lists.jboss.org Sent: Monday, June 13, 2011 2:29:41 PM Subject: [hibernate-dev] Processing mapping information followup Wanted to start a follow up discussion to the conversation we had at the IRC meeting on 6/13 with regards to changing the way we process mapping information to follow dependencies in the various types of information. What we do currently (in the metamodel code) is essentially the same as the legacy code. That is to say we process through a mapping source in full and then move on to the next one, saving off "second passes" whenever we encounter information on which we have to wait. The second passes in the new metamodel code are isolated I guess (so far) to org.hibernate.metamodel.source.internal.EntityReferenceResolver What I proposed instead is quite different, more like what I did for the rest of the MetadataImpl constructor code in terms of defining dependencies and processing stuff in an order that makes sure to avoid the need for second passes. Here is the initial swab at the levels of information: 1) entity - basic entity information such as name, hierarchy 2) identifiers - normal identifiers could almost be handled in the first level. key-many-to-one still needs some form of delayed queuing. 3) secondary tables 4) attributes 5) associations The dependencies flow downward; (2) depends on (1); (3) depends on (2); etc. I liked handling (3) secondary tables separately because they basically expand the possible set of columns available for (4) and (5).

Any idea how much this would affect tools ability to reflect on the metamodel without requiring the actual model classes and types to be available ? At what time will the classes/types be *required* to be available? i.e. for H3 as long as we filled out all the type info in the xml hibernate did not require access to types or model classes until buildMappings() occurred. Allowing us to iterate the mapped classes and tables for code generation. /max On Jun 13, 2011, at 23:29, Steve Ebersole wrote: > Wanted to start a follow up discussion to the conversation we had at the > IRC meeting on 6/13 with regards to changing the way we process mapping > information to follow dependencies in the various types of information. > > What we do currently (in the metamodel code) is essentially the same as > the legacy code. That is to say we process through a mapping source in > full and then move on to the next one, saving off "second passes" > whenever we encounter information on which we have to wait. The second > passes in the new metamodel code are isolated I guess (so far) to > org.hibernate.metamodel.source.internal.EntityReferenceResolver > > What I proposed instead is quite different, more like what I did for the > rest of the MetadataImpl constructor code in terms of defining > dependencies and processing stuff in an order that makes sure to avoid > the need for second passes. > > Here is the initial swab at the levels of information: > 1) entity - basic entity information such as name, hierarchy > 2) identifiers - normal identifiers could almost be handled in the first > level. key-many-to-one still needs some form of delayed queuing. > 3) secondary tables > 4) attributes > 5) associations > > The dependencies flow downward; (2) depends on (1); (3) depends on (2); etc. > > I liked handling (3) secondary tables separately because they basically > expand the possible set of columns available for (4) and (5). > > -- > Steve Ebersole&lt;steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen

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

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

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.

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

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

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.

>> 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. > > There are some tests in master Could you be a tad more specific ? Package or even a class name to narrow it down :)

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&quot;&lt;steve(a)hibernate.org&gt; To: "Max Rydahl Andersen&quot;&lt;max.andersen(a)redhat.com&gt; Cc: hibernate-dev(a)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.