[
http://opensource.atlassian.com/projects/hibernate/browse/HB-1014?page=co...
]
Arnout Engelen commented on HB-1014:
------------------------------------
I assume by 'added' you're referring to the hibernate.use_identifer_rollback
property
(
http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat...
It didn't appear to work for me, but that might be unrelated.
Hibernate does not remove ID's on a failed flush
------------------------------------------------
Key: HB-1014
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HB-1014
Project: Hibernate2
Type: Bug
Components: core
Versions: 2.1.4
Environment: 2.1.4
PostgreSQL
Most common in Swing applications
Reporter: Thomas Meeks
A thread about it:
http://forum.hibernate.org/viewtopic.php?t=931005
Conditions to recreate:
1. Create a new hibernate session (and transaction, if desired)
2. Create a transient object (that hibernate can persist)
3. Place the transient object in a known bad state (so that any attempt to persist it
will fail)
4. Attempt to save the object, which will fail
5. Close session, rollback txn
6. Fix the error with the object
7. Create a new hibernate session/txn
8. Attempt to save the object (which will currently fail, though it should not)
9. Close session
The error occurs at step 8. Because hibernate does not set the ID of the object to null,
it will assume that the object is in the database. When hibernate attempts to update the
object (rather than save), it will fail. This bug is particularily nasty when dealing with
cascades, as all objects will be assigned numbers.
A workaround:
Have your DAO layer keep track of new objects and manually set the ID to null /after/ the
session has closed (if you delete the ID before the session closes, hibernate will
complain about the changing of IDs).
This workaround can get quite messy, however, if one requires the use of cascades.
A (possible) real fix:
Have hibernate keep track of all new entities in the session, and upon failure, iterate
those entities and set their ID to null.
Another possibility (enumerated by gavin in the thread mentioned above) is to copy the
entire object tree by value, but this could cause real problems in objects with large byte
arrays.
The problem may be difficult to fix, however, I find the fact that the steps outlined
above do not work to be very counterintuitive. If not fixed, this bug should be at the
very least well documented.
The exception handling portion of the documentation does not indicate that all newly
saved objects must be thrown out if the session they are saved in has an exception.
--
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