*Description of problem: <class name="Person" table="PROPREF_PERS"> <id name="id"> <generator class="hilo"/> </id> <property name="name" length="100"/> <property name="userId" column="person_userid" length="8" unique="true" not-null="true"/> <one-to-one name="address" property-ref="person" cascade="all" fetch="join"/> <set name="accounts" inverse="true"> <key column="userId" property-ref="userId"/> <one-to-many class="Account"/> </set> <bag name="systems" table="USER_SYSTEM" lazy="true" inverse="false" cascade="all"> <key column="USER_ID" property-ref="userId" /> <element type="string" column="SYSTEM" /> </bag> </class> s.createQuery("delete from Person").executeUpdate(); generated sql: delete from USER_SYSTEM where (USER_ID) in (select id from PROPREF_PERS) should be: delete from USER_SYSTEM where (USER_ID) in (select userId from PROPREF_PERS) *Version-Release number of selected component (if applicable): EAP 6.3.0.ER7 Hibernate 4.2.13 *Steps to Reproduce: 1. run test org.hibernate.test.propertyref.basic.PropertyRefTest on postgresql or sybase 2. these test fail: testJoinFetchPropertyRef, testManyToManyPropertyRef, testOneToOnePropertyRef *Additional info: https://hibernate.atlassian.net/browse/HHH-9233
Thanks for investigating the test failures for HHH-9233. Looks like you found a regression. I sent email to Steve Ebersole about it. If it's not easy to fix quickly, I may end up reverting HHH-9222.
Thanks Gail, please let us know when the regression is confirmed/refuted. Although reverting HHH-9222 solves test failures, version 4.3.5 doesn't contain HHH-9222 and these tests fail too as reported by another user. I didn't play with 4.3.5, just 4.2.13.
I have verified that this does not affect 4.3.5. This bug was introduced into the 4.3 branch after 4.3.5 was released. The user that reported HHH-9233 is Mahesh Gadgil from SAP. Brett is working with him to fix some issues. I see on an email thread that he was working with the 4.3 branch. I asked him for confirmation about whether he saw the failure in 4.3.5 in a comment on HHH-9233. I'm guessing he picked that version as the affected version because 4.3.5 is the newest version released. I was going to release 4.3.6 today, but I've decided to wait until either HHH-9233 is fixed or HHH-9222 is reverted.
Mahesh has confirmed that he saw the test failure using the 4.3 branch.
Regression because of: s.createQuery("delete from Person").executeUpdate(); *EAP 6.2.0, hibernate 4.2.7.SP1: generated SQL: delete from PROPREF_PERS - it doesn't cascade delete to collection table USER_SYSTEM *EAP 6.3.0.ER7, hibernate 4.2.13.Final generated SQL: delete from USER_SYSTEM where (USER_ID) in (select id from PROPREF_PERS) - it tries to cascade delete to collection table (HHH-9222), but it generates wrong sql - causes error, e.g.: Implicit conversion from datatype 'VARCHAR' to 'BIGINT' is not allowed. Use the CONVERT function to run this query correct sql should be: delete from USER_SYSTEM where (USER_ID) in (select person_userid from PROPREF_PERS)
Steve originally fixed HHH-9222, and he has been on PTO since Wednesday. I investigated and I don't feel comfortable fixing HHH-9233 for 6.3.0 this late in the game. I'm concerned about introducing new regressions. HHH-9222 was classified as an "Improvement", not a "Bug", and it doesn't appear that any customer requested it. For these reasons, I would like to revert the fix for HHH-9222 (instead of fixing HHH-9233). Does anyone see a problem with doing so? I'm not clear on the process I should be following for these types of things and Brett is on PTO until some time next week.
I just discused this with Steve Ebersole and he's OK with reverting HHH-9222 (instead of fixing HHH-9233).
I created a new jira issue for reverting HHH-9222 on Hibernate 4.2 branch: HHH-9255. I've also moved the web link for this BZ to HHH-9255.
Fixed by upgrade https://bugzilla.redhat.com/show_bug.cgi?id=1111725
verified on EAP 6.3.0.ER9