[hibernate-dev] metamodel work

Steve Ebersole steve at hibernate.org
Tue May 22 18:06:40 EDT 2012

Grr, hit send too soon...

> I remember you mentioning that we may keep Configuration for a short time bridge. It seems to me that we would want a way to switch tests between the different sources of metadata.

I said we might keep Configuration as a class.  Never did I say it 
would do what it does today.

>> This transition from "Configuration metadata" to "new Metadata" is
>> just
>> that.. a transition.  I'd really rather not spend a lot of time
>> developing testing extensions for dealing with the transitory nature
>> of
>> this.
>> This "hibernate.test.new_metadata_mappings" setting is only pertinent
>> for tests that extend from
>> org.hibernate.testing.junit4.BaseCoreFunctionalTestCase.  In fact,
>> I'd
>> really say that it is only pertinent for tests of
>> functionality/features that have not yet been implemented in
>> metamodel
>> branch.
> I'm confused why you would say it's only pertinent for "tests of functionality/features that have not yet been implemented in metamodel branch". Are you saying that you'd only use hibernate.test.new_metadata_mappings=true to find out what fails?

Exactly.  Again, I dont expect new metamodel developed code to run 
through Configuration as it is today.

> I write new tests that extend BaseCoreFunctionalTestCase and set hibernate.test.new_metadata_mappings=true to confirm that functionality that has been piped into the persisters is working. If one of these tests fails somewhere down the line, that means that something in the metamodel or the persister code broke.

But you should write your test hard-coding 
hibernate.test.new_metadata_mappings=true in the tests.  Again, it is 
explicitly testing code that is targetting this new metamodel code.

steve at hibernate.org

More information about the hibernate-dev mailing list