[hibernate-dev] metamodel work

[Gail Badner]

I've been re-thinking what I wrote in my response below and would like to clarify some points. 

I'm going to move the tests that that I added to src/matrix to src/test. These tests are for simple use cases (e.g., unidirectional one-to-many, no subclasses, no join tables, ...) and are not database-dependent.

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.

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.

As "gaps" are filled in, it would be nice to be able to the same for the src/matrix tests.

In the future, as new functionality is added that only works using the new metamodel, it would be nice to be able to indicate that a test is expected to fail using the old Configuration metadata.

Thoughts?

Regards,
Gail
----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: hibernate-dev at 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 at hibernate.org>
> > To: hibernate-dev at 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 at hibernate.org
> > http://hibernate.org
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>