[hibernate-dev] HHH-5375 - Move AnnotationConfiguration-added methods to Configuration and deprecate AnnotationConfiguration

[Emmanuel Bernard]

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 <steve at 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 <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