[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229?page=c...
]
Gail Badner commented on HHH-3229:
----------------------------------
I've committed a test (org.hibernate.test.cascade.MultiPathCascadeTest) to Branch3_2
that show that the problem seems to only affect merging a detached entity. Using
Session.update() to update a detached entity and using Session.get() to get the entity
then modifying the entity works without throwing a TransientObjectException.
The failing test case that modifies a detached entity and uses Session.merge() is
MultiPathCascadeTest.testMultiPathMergeDetachedFailureExpected().
Make cascade rules more transparent/explicit/deterministic
----------------------------------------------------------
Key: HHH-3229
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3229
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.4.sp1, 3.2.5, 3.2.6
Reporter: Chris Bredesen
Cascade rules are prone to different behavior based on the order in which properties
appear in mapping XML. It is possible that an unexpected TransientObjectException may
arise from certain operations when an object graph with circular references is merged (and
possibly persisted/updated, etc).
For example, if a transient instance is reachable through more than once path from a root
entity, it is not clear whether operations will be cascaded to it. The order in which the
properties are mapped plays a part in determining cascade paths, but the rules are not
documented.
Possible resolutions include:
1. Documenting the rules so that a programmer can make educated decisions about mapping.
2. Enhancing the algorithm such that order no longer matters and the rules are
deterministic.
3. ???
--
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