[hibernate-dev] MetadataImpl ctor

Steve Ebersole steve at hibernate.org
Thu Jun 2 15:51:33 EDT 2011


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 at hibernate.org>
http://hibernate.org



More information about the hibernate-dev mailing list