[hibernate-dev] metamodel work
steve at hibernate.org
Tue May 22 18:02:33 EDT 2012
I said we might keep Configuration as a class. Never did I say it
would do what it does today.
On Tue 22 May 2012 05:01:18 PM CDT, Gail Badner wrote:
> 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.
> ----- Original Message -----
>> From: "Steve Ebersole"<steve at hibernate.org>
>> To: "Gail Badner"<gbadner at redhat.com>
>> Cc: hibernate-dev at lists.jboss.org
>> Sent: Tuesday, May 22, 2012 2:41:21 PM
>> Subject: Re: [hibernate-dev] metamodel work
>> This transition from "Configuration metadata" to "new Metadata" is
>> that.. a transition. I'd really rather not spend a lot of time
>> developing testing extensions for dealing with the transitory nature
>> This "hibernate.test.new_metadata_mappings" setting is only pertinent
>> for tests that extend from
>> org.hibernate.testing.junit4.BaseCoreFunctionalTestCase. In fact,
>> really say that it is only pertinent for tests of
>> functionality/features that have not yet been implemented in
> 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?
> < If a test is specifically testing new metamodel branch code,
>> am not sure why it is dependent on
>> "hibernate.test.new_metadata_mappings" at all.
>>> I would like to be able to run these tests (that I move to
>>> src/test) using both the old and new types of metamedata so I can:
>>> 1) ensure that the test passes for both types of metadata;
>>> 2) detect at a later date if some change was made that broke the
>>> test for either type of metadata;
>>> 3) easily compare the SQL that gets generated from both types of
>>> metadata to see if there are any differences; if there are
>>> differences, at this point (at least), they'd probably be due to
>>> something not yet implemented in the new metamodel.
>> Why are you writing new tests and wanting to have it run against the
>> the old Configuration setup? I think this is the central part I am
> 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.
>>> I'd like to be able to run all the "test" tests (i.e., excluding
>>> the "matrix" tests) using hibernate.test.new_metadata_mappings set
>>> to true. Currently, there are 29 failures. It would be nice to be
>>> able to indicate (e.g., using an annotation) that a test is
>>> expected to fail using the new metamodel.
>> Well again, to me this "hibernate.test.new_metadata_mappings" is an
>> explicitly transitory thing. Yep there are failures. We know there
>> are failures. We expect that until we finish implementing features
>> the new metamodel code there will continue to be failures. But this
>> exactly why "hibernate.test.new_metadata_mappings" is false by
>> steve at hibernate.org
steve at hibernate.org
More information about the hibernate-dev