[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584?page=c...
]
SoWeLie commented on HHH-2584:
------------------------------
This seems to still be an issue in 3.3.1. When I call remove on an uninitialized map, the
object is not removed. If I do something like call the values method, then try the
remove, the object is removed properly.
PersistentMap.remove() incorrect on uninitialized, non-extra-lazy
map
---------------------------------------------------------------------
Key: HHH-2584
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584
Project: Hibernate Core
Issue Type: Patch
Components: core
Affects Versions: 3.2.1, 3.2.2, 3.2.3
Environment: Hibernate 3.2.3 ga, MySQL 5.0.24a, for Win32
Reporter: Daniel Wellman
Assignee: Diego Plentz
Attachments: persistentmap_remove.patch
This problem is nearly identical to HHH-2476: PersistentMap.put() incorrect on
uninitialized, non-extra-lazy map. remove() has the same problem. See also issue
HHH-2142.
The write up for HHH-2476 was so concise that I will transform it here, substituting
remove() for put().
---
Essentially, an uninitialized PersistentMap loses the first remove() into it if defined
as non-extra-lazy.
The underlying cause is the code in PersistentMap#remove() which attempts to
readElementByIndex(). In the case of non-extra-lazy, readElementByIndex() returns the
UNKNOWN marker object which is supposed to be used to signal that the delegate map is now
initialized and to remove the element directly from the map. Long story short,
PersistentMap#remove() does not properly check the return value from readElementByIndex()
and react accordingly.
--
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