[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c...
]
Gail Badner commented on HHH-1296:
----------------------------------
The patch is really not appopriate. There should be a constraint on child ID in the link
table for a one-to-many association. I you require that a child be in a collection more
than once, or in multiple collections, then the collection should be mapped as
many-to-many.
There is definitiely a bug in how Hibernate updates rows after a deleting an element of a
collection mapped as one-to-many. This issue will be fixed by HHH-3160.
The workaround mentioned in HHH-3160 is:
"For one-to-many list associations on a foreign key, the workaround is to define the
unique constraint on (owner_id, position) in the child entity table as deferred. It is
assumed that the primary key in the child entity table is the child ID.
For a one-to-many list association on a join table, the workaround is to define the
constraint on (child_id) in the join table as deferred. It is assumed that the primary key
in the join table is (owner_id, position).
If your Dialect does not support deferred constraints, then the only workaround is to
exclude the unique constraint."
Non lazy loaded List updates done in wrong order, cause exception
-----------------------------------------------------------------
Key: HHH-1296
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.0.5
Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 &
5, db2 v8)
NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is
not allowed.
Reporter: David Birch
Assignee: Diego Pires Plentz
Priority: Critical
Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA
who won't let up...)
The scenario is:
a bean with list property, and the list has a number of items in it (say 4, index 0-3),
an item is then removed (say item at index 2), and the bean is requested to be saved.
From what i can see in the SQL traces, the same statements are issues whe lazy loading is
on or off, they are:
[18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from
TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
[18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY
set POLICY_NK=? where CLIENT_ID=? and POSITION=?
So, i can only assume (as when this fails, the row with index 1 above the removed row is
nuked!), hibernate removes the item at index 3, and then copies the value of the item at
index 3 onto the row for item at index 2. Fair enough but...
When i have lazy loading off, i get DB exceptions like
Duplicate key or integrity constraint violation message from server: "Duplicate
entry '1-999999' for key 1"
so, there is some nasty in there, which is not updating the correct row - this has
happened since 2.1.8 that i know of :(
i will try & look @ the source, but won't get a chance until after xmas...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira