[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4642?page=c...
]
Gail Badner updated HHH-4642:
-----------------------------
Comment: was deleted
(was: A workaround to persist changes made to a read-only entity are:
// make the entity, dp, read-only
s.setReadOnly( dp, true );
// modify the read-only entity, possibly inadvertantly
dp.setDescription( "changed" );
// need to evict dp to keep it's modified state
s.evict( dp );
// add the modified entity to the session
s.update( dp );
// now dp is not read-only and its changes will be flushed
s.flush();)
Unexpected results when an entity with non-flushed changes is changed
from read-only to modifiable
--------------------------------------------------------------------------------------------------
Key: HHH-4642
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4642
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2, 3.5.0.Beta-1, 3.5.0-Beta-2
Reporter: Gail Badner
Assignee: Gail Badner
When an entity is changed from being read-only to modifiable, its snapshot is created
from its current state (in the session), not its persistent state (in the DB).
This can cause unexpected results when:
- an entity had non-flushed changes when it was set to read-only, or
- an entity's state (in the session) was changed after being made read-only.
If no other changes are made to the entity after being made modifiable, Hibernate will
not detect that the entity is dirty, and those changes will not be pushed to the DB. If
other changes are made, Hibernate will detect that the entity is dirty, and the newer
changes will be persisted, but the older changes may not be.
--
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