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"<st...@hibernate.org> >> To: "Gail Badner"<gbad...@redhat.com> >> Cc: hibernate-dev@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 >> 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? > > < If a test is specifically testing new metamodel branch code, >> I >> 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 >> missing. >> > > 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 >> in >> the new metamodel code there will continue to be failures. But this >> is >> exactly why "hibernate.test.new_metadata_mappings" is false by >> default. >> >> >> -- >> st...@hibernate.org >> http://hibernate.org >> -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
