http://opensource.atlassian.com/projects/hibernate/browse/HHH-5375
In attempting this I ran into the difference between Configuration and AnnotationConfiguration of processing mapping files (hbm.xml). Configuration tries to process these immediately, whereas AnnotationConfiguration delays that attempt. So merging these 2 would require changing the behavior in Configuration to delay attempts to process/bind hbm.xml files to match what is done in AnnotationConfiguration. What's the ramification? Well previously Configuration would allow a developer to do, as an example, stuff like: Configuation cfg = ...; cfg.setProperty( "hibernate.default_schema", "ABC" ); cfg.addResource( "SomeEntity.hbm.xml" ); cfg.setProperty( "hibernate.default_schema", "XYZ" ); cfg.addResource( "AnotherEntity.hbm.xml" ); When "SomeEntity.hbm.xml" gets processed, the default schema in effect is "ABC"; when "AnotherEntity.hbm.xml" gets processed, it is "XYZ". Now this has never been explicitly supported, but it is a side effect of the lack of a "lifecycle" to how configurations are built (this will be addresses in 4.x). Now I am pretty sure we have consistently said that the above is not supported and that user should not expect the "added" metadata to be available until after buildMappings() has been called. In fact, what those calls should look like would be: Configuation cfg = ...; cfg.setProperty( "hibernate.default_schema", "ABC" ); cfg.addResource( "SomeEntity.hbm.xml" ); cfg.buildMappings(); cfg.setProperty( "hibernate.default_schema", "XYZ" ); cfg.addResource( "AnotherEntity.hbm.xml" ); cfg.buildMappings(); which has the same effect today as the code above, and will continue to have the same effect moving forward even if we have Configuation delay the processing/binding. So I'd like to get input on whether we make this change today (for 3.6) and merge Configuration+AnnotationConfiguation into a single class[1], or if we push this back until 4.x when we begin the rest of the configuration changes. [1] Really the intent is move methods/fields from AnnotationConfiguation up to Configuation and deprecate AnnotationConfiguation. That way existing code can, for s short time, continue to use AnnotationConfiguration without change. -- 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
