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 <st...@hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
