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. -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
