[hibernate-dev] Test success may not mean functionality is correct

[Gail Badner]

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