Seems to make sense from my perspective, but I'm the least familiar with this code.
On Jun 2, 2011, at 3:24 PM, Steve Ebersole wrote: > 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 <st...@hibernate.org> > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev JPAV _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev