[hibernate-dev] MetadataImpl ctor

[John Verhaeg]

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

JPAV