Late in the game but we discussed the topic. I would go for the move in the next 3.6 beta to give people chance to test it.
On 14 juil. 2010, at 18:54, Steve Ebersole <st...@hibernate.org> wrote: > 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
