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

[Steve Ebersole]

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.


On Thu 09 Aug 2012 11:27:52 AM CDT, Steve Ebersole wrote:
> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> --
>> steve at hibernate.org
>> http://hibernate.org
>
> --
> steve at hibernate.org
> http://hibernate.org

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