I've seen some cases where tests are passing for functionality that is not yet implemented. In these cases, generated DDL for the new metamodel is incorrect. For example: org.hibernate.test.annotations.genericsinheritance.GenericsInheritanceTest Generated DDL using old metamodel: create table ChildHierarchy1 (id bigint not null, parent_id bigint, primary key (id)) create table ChildHierarchy22 (id bigint not null, parent_id bigint, primary key (id)) create table ParentHierarchy1 (id bigint not null, primary key (id)) create table ParentHierarchy22 (id bigint not null, primary key (id)) alter table ChildHierarchy1 add constraint FK3D9D8AB8B84C10B6 foreign key (parent_id) references ParentHierarchy1 alter table ChildHierarchy22 add constraint FK7613CC99DB2D4DFB foreign key (parent_id) references ParentHierarchy22 create sequence hibernate_sequence start with 1 increment by 1 Generated DDL using new metamodel: create table ParentHierarchy1 (id bigint not null, primary key (id)) create table ChildHierarchy1 (id bigint not null, primary key (id)) create table ParentHierarchy22 (id bigint not null, primary key (id)) create table ChildHierarchy22 (id bigint not null, primary key (id)) create sequence hibernate_sequence start with 1 increment by 1 --------------- org.hibernate.test.annotations.onetoone.OptionalOneToOneMappedByTest Generated DDL using old metamodel: create table Owner (id integer not null, primary key (id)) create table OwnerAddress (id integer not null, primary key (id)) create table Party (partyId varchar(255) not null, primary key (partyId)) create table PartyAffiliate (partyId varchar(255) not null, affiliateName varchar(255), primary key (partyId)) create table Person (id integer not null, primary key (id)) create table PersonAddress (id integer not null, primary key (id)) Generated DDL using new metamodel: create table Owner (id integer not null, address integer, primary key (id)) create table OwnerAddress (id integer not null, owner integer, primary key (id)) create table Party (partyId varchar(255) not null, partyAffiliate varchar(255), primary key (partyId)) create table PartyAffiliate (partyId varchar(255) not null, affiliateName varchar(255), party varchar(255), primary key (partyId)) create table Person (id integer not null, personAddress integer, primary key (id)) create table PersonAddress (id integer not null, person integer, primary key (id)) IMO, the DDL generated using the new metamodel should be compared with that generated using the old metamodel to confirm they are consistent. IMO, a good start is to simply use what is generated by the old metamodel as a baseline. >From what I've seen so far, I can tell that something is wrong just by looking at the DDL. If I see cases where the DDL is correct, but generated SQL is incorrect, then I would also like to see the static SQL generated by the persisters and other queries compared as well. I understand that there will be new functionality added to the metamodel branch where this comparison will not be possible. If necessary, we can work something out for these cases; for example, creating a baseline after manually verifying the generated DDL and SQL. There are different ways this could be accomplished. I want to pass this by everyone before digging into how it should be implemented. WDYT? Regards, Gail _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I hooked in using the new schema management tool code to handle schema create/drop processing. These particular FKs are still not being created. So I looked at the tests a little closer. The issue there is that code building the bindings are not always creating Database objects. Specifically here it seems to be FKs related to joined inheritance. On Tue 07 Aug 2012 08:32:42 AM CDT, Steve Ebersole wrote: > Perhaps we should actually hook in the new schema management code > before we start worrying about missing DDL bits? ;) > > As it is right now, building the SessionFactory through the Metamodel > is still just using SchemaExport to the hacked-together > Database#generateSchemaCreationScript and > Database#generateDropSchemaScript methods that are very rough > approximations of the older Configuration#generateSchemaCreationScript > and Configuration#generateDropSchemaScript. The miss lots of stuff > from the older Configuration ones. > > That being said, if you really want to be able to do this there are 2 > viable ways. And we know this because we have discussed this very > thing 3 times now... > > 1) Store off the SQL (DDL/DML) you are interested in somewhere, > somehow per-test. This gives you your "base line" against which you > can go back and check later if/when you need. You'd just need a > script that instantiates all the tests and builds their respective > Configuration/SessionFactory and grabs the SQL you want. > > 2) Write tests whose test phase is asserting the comparison between > the old and new SQL. This is not at all as simple as it sounds as our > experience taught us with testing the Antlr-based HQL parser by > comparing its output against the output of the previous parser. But > it is also the best "automated way" to see if something regresses. > > > On Tue 07 Aug 2012 01:56:04 AM CDT, Gail Badner wrote: >> I've seen some cases where tests are passing for functionality that >> is not yet implemented. In these cases, generated DDL for the new >> metamodel is incorrect. >> >> For example: >> >> org.hibernate.test.annotations.genericsinheritance.GenericsInheritanceTest >> >> >> >> Generated DDL using old metamodel: >> >> create table ChildHierarchy1 (id bigint not null, parent_id bigint, >> primary key (id)) >> create table ChildHierarchy22 (id bigint not null, parent_id bigint, >> primary key (id)) >> create table ParentHierarchy1 (id bigint not null, primary key (id)) >> create table ParentHierarchy22 (id bigint not null, primary key (id)) >> alter table ChildHierarchy1 add constraint FK3D9D8AB8B84C10B6 foreign >> key (parent_id) references ParentHierarchy1 >> alter table ChildHierarchy22 add constraint FK7613CC99DB2D4DFB >> foreign key (parent_id) references ParentHierarchy22 >> create sequence hibernate_sequence start with 1 increment by 1 >> >> Generated DDL using new metamodel: >> >> create table ParentHierarchy1 (id bigint not null, primary key (id)) >> create table ChildHierarchy1 (id bigint not null, primary key (id)) >> create table ParentHierarchy22 (id bigint not null, primary key (id)) >> create table ChildHierarchy22 (id bigint not null, primary key (id)) >> create sequence hibernate_sequence start with 1 increment by 1 >> >> --------------- >> >> org.hibernate.test.annotations.onetoone.OptionalOneToOneMappedByTest >> >> Generated DDL using old metamodel: >> >> create table Owner (id integer not null, primary key (id)) >> create table OwnerAddress (id integer not null, primary key (id)) >> create table Party (partyId varchar(255) not null, primary key >> (partyId)) >> create table PartyAffiliate (partyId varchar(255) not null, >> affiliateName varchar(255), primary key (partyId)) >> create table Person (id integer not null, primary key (id)) >> create table PersonAddress (id integer not null, primary key (id)) >> >> Generated DDL using new metamodel: >> >> create table Owner (id integer not null, address integer, primary key >> (id)) >> create table OwnerAddress (id integer not null, owner integer, >> primary key (id)) >> create table Party (partyId varchar(255) not null, partyAffiliate >> varchar(255), primary key (partyId)) >> create table PartyAffiliate (partyId varchar(255) not null, >> affiliateName varchar(255), party varchar(255), primary key (partyId)) >> create table Person (id integer not null, personAddress integer, >> primary key (id)) >> create table PersonAddress (id integer not null, person integer, >> primary key (id)) >> >> IMO, the DDL generated using the new metamodel should be compared >> with that generated using the old metamodel to confirm they are >> consistent. IMO, a good start is to simply use what is generated by >> the old metamodel as a baseline. >> >> >From what I've seen so far, I can tell that something is wrong just >> by looking at the DDL. If I see cases where the DDL is correct, but >> generated SQL is incorrect, then I would also like to see the static >> SQL generated by the persisters and other queries compared as well. >> >> I understand that there will be new functionality added to the >> metamodel branch where this comparison will not be possible. If >> necessary, we can work something out for these cases; for example, >> creating a baseline after manually verifying the generated DDL and SQL. >> >> There are different ways this could be accomplished. I want to pass >> this by everyone before digging into how it should be implemented. >> >> WDYT? >> >> Regards, >> Gail >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > steve(a)hibernate.org > http://hibernate.org -- steve(a)hibernate.org http://hibernate.org

From: "Hardy Ferentschik" <hardy(a)hibernate.org&gt; To: "Steve Ebersole" <steve(a)hibernate.org&gt; Cc: "Gail Badner" <gbadner(a)redhat.com&gt;, "Hibernate hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; Sent: Thursday, August 9, 2012 12:04:37 PM Subject: Re: [hibernate-dev] Test success may not mean functionality is correct On 9 Jan 2012, at 8:32 PM, Steve Ebersole wrote: > OK, I added adding FK between joined inheritance tables but > org.hibernate.test.annotations.genericsinheritance.GenericsInheritanceTest > still fails. AFAICT the problem there is that joined inheritance > is > considered the default if no inheritance type is specified (at > least > based on the old DDL ouptut..). But that case does not seem to be > handled at all in annotation source. > > org.hibernate.test.annotations.onetoone.OptionalOneToOneMappedByTest > still fails as well, because either one-to-one is not implemented > or > does not create FKs either. I was planning to look in the one-to-x mappings once I am back, unless anyone else picks it up until then. --Hardy