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

[Steve Ebersole]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

--
steve at hibernate.org
http://hibernate.org