Re: [hibernate-dev] MetadataImpl ctor

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.