I guess one thing I am interested in is whether you see an issue in this style of process with annotations. On the HBM side of things, this will work out beautifully. Do you foresee any issues with this on the annotation side? On 06/02/2011 02:51 PM, Steve Ebersole wrote: > Hardy, et al. > > I have been working mostly on low-hanging fruit in this metamodel code > getting a handle on the code y'all wrote. > > I wanted to discuss one proposal for change in particular. Currently the > ctor for MetadataImpl decides whether to process HBM or annotations > first and then processes all of that type completely, then moves on to > the other type. > > > What I wanted to propose instead was that we process the incoming data > more in chunks (for lack of better vocab). Basically the thought is that > there is a natural order to the things based on the nature of how they > relate to each other and their potential inter-dependence. > > I think psuedo code works well here to illustrate what I propose. > Currently we do (assuming HBM as precendence): > > MetadataImpl(...) { > processHibernateMappings(...); > processAnnotations(...); > } > > processHibernateMappings(...) { > for ( allHibernateMappingFiles ) { > process( individualHibernateMapping ); > } > } > > > I understand why we did it this way. Its exactly what the legacy code does. > > More what I had in mind though is: > > MetadataImpl(...) { > // auxiliary database objects are independent > processAuxiliaryDatabaseObjects(...); > > // type definitions are independent > processTypeDefinitions(...); > > // filters potentially depend on type definitions > processFilterDefinitions(...); > > // id gen definitions potentially depend on type definitions > processIdentifierGenerators(...); > > ... > } > > processAuxiliaryDatabaseObjects(...) { > // TODO : not sure "source precedence" means anything other than > // in regards to entity definitions > for ( allSources ) { > selectBinder(...).bindAuxiliaryDatabaseObjects(...); > } > } > > There are a couple of reasons why it seems better to me to do it this > way. There are 2 bigs ones imo: > > 1) The fact that we know all the things we need to perform each > processXXX before we do it, which is a general theme in this start up > redesign. An example of where this is helpful is in type definitions (on > the hbm side at least). Currently users need to ensure, themselves, that > all type definitions are added before attempting to add entities, id > generators, etc that try to reference those types. The proposed approach > would allow the code to be more user helpful because it would do that > for them. > > 2) Partially a consequence of the first, we can validate as we go. > -- Steve Ebersole <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