From: "Gail Badner" <gbadner(a)redhat.com&gt; To: "Steve Ebersole" <steve(a)hibernate.org&gt; Cc: hibernate-dev(a)lists.jboss.org Sent: Friday, May 18, 2012 2:51:27 PM Subject: Re: [hibernate-dev] metamodel work Hi Steve, That's great that we can use the mapping files as-is for both -Dhibernate.test.new_metadata_mappings=true and =false settings. There are already some tests that hard-code configuring USE_NEW_METADATA_MAPPINGS=true and that have the new-style: <hibernate-mapping package="org.hibernate.test.ops" xmlns="http://www.hibernate.org/xsd/hibernate-mapping" xsi:schemaLocation="http://www.hibernate.org/xsd/hibernate-mapping hibernate-mapping-4.0.xsd" xmlnssi="http://www.w3.org/2001/XMLSchema-instance"> IIRC, these tests basically duplicate older tests that use Configuration-based metadata. With your new changes, it seems that the tests that hard-code USE_NEW_METADATA_MAPPINGS=true along with the duplicated mapping files can be removed. If the original tests (w/o the hard-coded hard-code USE_NEW_METADATA_MAPPINGS=true) pass using -Dhibernate.test.new_metadata_mappings=true, is there a way to indicate that those tests are expected to pass when using the new metamodel? I want to be sure that if these tests fail later using -Dhibernate.test.new_metadata_mappings=true, that we find out that a bug in the new metamodel has been introduced. As we fix the "gaps", I would imagine we'd want to do the same with other tests that are verified to work with the new metamodel. WDYT? Gail ----- Original Message ----- > From: "Steve Ebersole" <steve(a)hibernate.org&gt; > To: hibernate-dev(a)lists.jboss.org > Sent: Friday, May 18, 2012 10:27:41 AM > Subject: [hibernate-dev] metamodel work > > Just a heads up of a few things for those of us working on the > metamodel > branch. > > 1) I just added the ability to have legacy-style HBM mappings parse > properly using the JaxbHelper. This is awesome because it allows > us > to > keep the test mappings as-is for the time being and use them in > both > the > older Configuration approach or the new metamodel approach, which > is > awesome in conjunction with... > 2) Better passing of command-line system props to tests. I changed > the > gradle script a little bit to pass any command line argument system > property (-D) that starts with 'hibernate.' along to the process > used > to > run the tests. So now, for example, specifying > `-Dhibernate.test.new_metadata_mappings=true` on the gradle command > line > actually gets that setting passed along to the tests as a system > property. > 3) Maybe this is useful in testing, maybe it isnt but a related > change > made along with (1) was the ability to disable XML validation. The > setting that controls this is 'hibernate.xml.validate' (default = > true). > > Next week I will start focusing on running the full test suite > using > the > new_metadata_mappings settings enabled and start working on the > "gaps" I > find. > > -- > steve(a)hibernate.org > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: "Gail Badner" <gbadner(a)redhat.com&gt; Cc: hibernate-dev(a)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 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'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. -- steve(a)hibernate.org http://hibernate.org

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.

> 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?

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.

From: "Hardy Ferentschik" <hardy(a)hibernate.org&gt; To: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Wednesday, May 23, 2012 3:34:38 AM Subject: Re: [hibernate-dev] metamodel work On May 22, 2012, at 11:41 PM, Steve Ebersole wrote: > 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. +1 I also cannot imagine that we can keep both code paths (new and old configuration/metadata) working for ever. At some stage we will have to wire up the new stuff for good and I don't think this is possible without breaking old code and tests.

It might be a good idea to have to checkouts. One with the current HEAD of the metamodel work and one with the old code still in place. Instead of doing everything on one checkout work in two different checkouts with two IDE windows etc.

This is probably even more effective, since now you can really compare things side by side. I am not doing this yet, since in the current state of the metamodel the test targeting just the metamodel are independent of any settings (as Steve already pointed out).

--Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: "Gail Badner" <gbadner(a)redhat.com&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt;, "Hardy Ferentschik" <hardy(a)hibernate.org&gt; Sent: Wednesday, May 23, 2012 11:14:09 AM Subject: Re: [hibernate-dev] metamodel work On Wed 23 May 2012 01:05:19 PM CDT, Gail Badner wrote: > I seem to be the only one writing tests that extend > BaseCoreFunctionalTestCase with > hibernate.test.new_metadata_mapping=true. I've been doing this to > ensure that the metamodel info is translated into the persisters > properly and that standard operations (i.e., SQL and bound > parameters) are being executed properly. Well thats also not the only way to write tests for targetting the new metamodel. Most of the tests I write at least for metamodel work are in fact not functional tests. So I don't try to to fit them into there since they don't fit.

> TBH, I find it interesting that the people that are not actually > doing this work think that simply being able to toggle a > configuration parameter is a waste of time... Has nothing to do with toggling a switch. Really you are forcing that Configuration (as is) and org.hibernate.mapping be kept around past their useful lifecycle because now you are introducing tests that require that. This is the exact same story I related to you wrt HQL testing. And actually its even worse than the HQL tests because here there arent even assertions that assert that both paths result in the same thing; instead you just manually check that by eye.

-- steve(a)hibernate.org http://hibernate.org

> Well thats also not the only way to write tests for targetting the > new > metamodel. Most of the tests I write at least for metamodel work are > in fact not functional tests. So I don't try to to fit them into > there > since they don't fit. I agree it's not the only way to write tests. It is a simple way that helps me do my work. I also agree these are not functional tests. They are more like use case tests, as are many of the matrix tests. They test that it works end-to-end.