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(a)hibernate.org
http://hibernate.org