I was not yet able to recreate in the org.hibernate.test.event.collection.detached.BadMergeHandlingTest last night. I'm taking another look at getting more information from the failing TCK test that might clue us in on what to change in the test. I did find that If I change the following in the TCK test (as suggested by Steve):
// the TCK test will now pass
aliasRef[2].getCustomers().add(customerRef[0]);
aliasRef[2] = getEntityManager().merge(aliasRef[2]);
// the TCK test will fail
aliasRef[2].getCustomers().add(customerRef[0]);
getEntityManager().merge(aliasRef[2]);
Now that I know which of the many "merge" calls are important to focus on, I'm going to log more details about the (original) passed Alias and the Alias returned.
Also, I did enable SQL/PARAMETER logging for the TCK failure case which shows the unexpected extra (duplicate row):
22:38:37,513 DEBUG [org.jboss.as.jpa] (EJB default - 2) EJB default - 2:[transaction scoped EntityManager]: created entity manager session TransactionImple < ac, BasicAction: 0:ffff7f000001:-7c5295fa:50f770d9:30 status: ActionStatus.RUNNING >
22:38:37,520 TRACE [org.jboss.as.jpa] (EJB default - 2) createQuery took 7ms
22:38:37,521 DEBUG [org.hibernate.SQL] (EJB default - 2)
select
customer0_.ID as ID152_,
customer0_.code as code152_,
customer0_.country as country152_,
customer0_.FK6_FOR_CUSTOMER_TABLE as FK5_152_,
customer0_.NAME as NAME152_,
customer0_.FK5_FOR_CUSTOMER_TABLE as FK6_152_
from CUSTOMER_TABLE customer0_
inner join FKS_ALIAS_CUSTOMER aliases1_
on customer0_.ID=aliases1_.FK_FOR_CUSTOMER_TABLE
inner join ALIAS_TABLE alias2_ on aliases1_.FK_FOR_ALIAS_TABLE=alias2_.ID
where alias2_.ALIAS=? fetch first 20 rows only
22:38:37,526 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (EJB default - 2) binding parameter [1] as [VARCHAR] - fish
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [1] as column [ID152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [USA] as column [code152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [United States] as column [country152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [1] as column [FK5_152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [Alan E. Frechette] as column [NAME152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [2] as column [FK6_152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [1] as column [ID152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [2] as column [ID152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [USA] as column [code152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [United States] as column [country152_]
22:38:37,528 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [3] as column [FK5_152_]
22:38:37,529 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [Arthur D. Frechette] as column [NAME152_]
22:38:37,529 TRACE [org.hibernate.type.descriptor.sql.BasicExtractor] (EJB default - 2) Found [4] as column [FK6_152_]
The TCK test failure shows the expected and actual PK values:
22:38:37,542 INFO [stdout] (EJB default - 2) ERROR: Wrong collection size returned (expected 2, got 3)
22:38:37,542 INFO [stdout] (EJB default - 2) ERROR: Wrong ejb's returned, expected PKs of (1, 2), got PKs of (1, 1, 2)
22:38:37,543 INFO [stdout] (EJB default - 2) ERROR: Did not get expected results. Expected 2 references, got: 3
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
I was not yet able to recreate in the org.hibernate.test.event.collection.detached.BadMergeHandlingTest last night. I'm taking another look at getting more information from the failing TCK test that might clue us in on what to change in the test. I did find that If I change the following in the TCK test (as suggested by Steve):
// the TCK test will now pass aliasRef[2].getCustomers().add(customerRef[0]); aliasRef[2] = getEntityManager().merge(aliasRef[2]);
// the TCK test will fail aliasRef[2].getCustomers().add(customerRef[0]); getEntityManager().merge(aliasRef[2]);
Now that I know which of the many "merge" calls are important to focus on, I'm going to log more details about the (original) passed Alias and the Alias returned.
Also, I did enable SQL/PARAMETER logging for the TCK failure case which shows the unexpected extra (duplicate row):
The TCK test failure shows the expected and actual PK values: