[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Steve Ebersole updated HHH-5472: -------------------------------- Fix Version/s: (was: 3.6.0.CR2) 3.6.x -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Gail Badner updated HHH-5472: ----------------------------- Fix Version/s: (was: 3.6.1) 4.0.0.Alpha2 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Steve Ebersole commented on HHH-5472: ------------------------------------- I'm assuming this is going to have to wait for Beta1 or later? Just trying to get the Alpha3 issues cleaned up a bit in prep for release. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Gail Badner updated HHH-5472: ----------------------------- Fix Version/s: (was: 4.0.0.Beta1) 4.0.0.next -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Gail Badner updated HHH-5472: ----------------------------- Fix Version/s: (was: 4.0.0.next) 4.1.0 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Steve Ebersole updated HHH-5472: -------------------------------- Fix Version/s: (was: 4.1.0) 5.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Gail Badner updated HHH-5472: ----------------------------- Description: The proposed fix will have no affect on the cascade algorithm itself. IOW, EntityInsertAction and EntityIdentityInsertAction objects will be added to the ActionQueue in the same order as before. Preposed algorithm: 1) When an EntityInsertAction or EntityIdentityInsertAction object is added to the ActonQueue,find any transient entities that would cause the insert to fail; 2) If the entity insert action would fail due to non-nullable transient entities, then that action is added to ActionQueue as an "unresolved" insert action. 3) Otherwise, execute ActionQueue.addResolvedEntityInsertAction( insert ) which: 3a) the action is processed (i.e., added to ActionQueue.insertions or executed); 3b) the entity status is changed to Status.MANAGED; 3c) resolve dependencies that "unresolved" insert actions have on the entity; 3d) if any "unresolved" insert actions no longer have any non-nullable transient entity dependencies, then process as a "resolved" insert action by executing 3). 4) If ActionQueue still has unresolved entity insert actions when the operation completes, then TransientObjectException is thrown. This model (used by org.hibernate.test.annotations.cascade.multicircle tests) illustrates the proposed fix: ------------------------------ N G | | 1 | | | | | N | | E N--------------0,1 * F | | 1 N | | | | | | 1 N | * | B * N---1 D * 1------------------ * N N | | | | 1 | | C * 1----- In the diagram: - all associations are bidirectional. - assocations marked with '*' cascade persist, save, merge operations to the associated entities (e.g., B cascades persist to D, but D does not cascade persist to B) If b, c, d, e, f, and g are all transient unsaved that are associated with each other, then when Session.persist( b ) is called, then entities are added to the ActionQueue in the following order: c, d (depends on e), f (depends on d, g), e, b, g Before the fix, entities would be inserted in the same order they were added to the ActionQueue, resulting in an exception when saving d (because d.e is non-nullable and transient) Using the proposed fix, entities will be successfully inserted in the following order: c, e, d, b, g, f In this case, inserting d is delayed until after e is inserted, and inserting f is delayed until after e and g are inserted. was:Details to follow... Pull Requests: https://github.com/hibernate/hibernate-core/pull/240 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Gail Badner updated HHH-5472: ----------------------------- Description: The proposed fix will have no affect on the cascade algorithm itself. IOW, EntityInsertAction and EntityIdentityInsertAction objects will be added to the ActionQueue in the same order as before. Preposed algorithm: 1) When an EntityInsertAction or EntityIdentityInsertAction object is added to the ActonQueue,find any transient entities that would cause the insert to fail; 2) If the entity insert action would fail due to non-nullable transient entities, then that action is added to ActionQueue as an "unresolved" insert action. 3) Otherwise, execute ActionQueue.addResolvedEntityInsertAction( insert ) which: 3a) the action is processed (i.e., added to ActionQueue.insertions or executed); 3b) the entity status is changed to Status.MANAGED; 3c) resolve dependencies that "unresolved" insert actions have on the entity; 3d) if any "unresolved" insert actions no longer have any non-nullable transient entity dependencies, then process as a "resolved" insert action by executing 3). 4) If ActionQueue still has unresolved entity insert actions when the operation completes, then TransientObjectException is thrown. This model (used by org.hibernate.test.annotations.cascade.multicircle tests) illustrates the proposed fix: {noformat} ------------------------------ N G | | 1 | | | | | N | | E N--------------0,1 * F | | 1 N | | | | | | 1 N | * | B * N---1 D * 1------------------ * N N | | | | 1 | | C * 1----- {noformat} In the diagram: - all associations are bidirectional. - assocations marked with '*' cascade persist, save, merge operations to the associated entities (e.g., B cascades persist to D, but D does not cascade persist to B) If b, c, d, e, f, and g are all transient unsaved that are associated with each other, then when Session.persist( b ) is called, then entities are added to the ActionQueue in the following order: c, d (depends on e), f (depends on d, g), e, b, g Before the fix, entities would be inserted in the same order they were added to the ActionQueue, resulting in an exception when saving d (because d.e is non-nullable and transient) Using the proposed fix, entities will be successfully inserted in the following order: c, e, d, b, g, f In this case, inserting d is delayed until after e is inserted, and inserting f is delayed until after e and g are inserted. was: The proposed fix will have no affect on the cascade algorithm itself. IOW, EntityInsertAction and EntityIdentityInsertAction objects will be added to the ActionQueue in the same order as before. Preposed algorithm: 1) When an EntityInsertAction or EntityIdentityInsertAction object is added to the ActonQueue,find any transient entities that would cause the insert to fail; 2) If the entity insert action would fail due to non-nullable transient entities, then that action is added to ActionQueue as an "unresolved" insert action. 3) Otherwise, execute ActionQueue.addResolvedEntityInsertAction( insert ) which: 3a) the action is processed (i.e., added to ActionQueue.insertions or executed); 3b) the entity status is changed to Status.MANAGED; 3c) resolve dependencies that "unresolved" insert actions have on the entity; 3d) if any "unresolved" insert actions no longer have any non-nullable transient entity dependencies, then process as a "resolved" insert action by executing 3). 4) If ActionQueue still has unresolved entity insert actions when the operation completes, then TransientObjectException is thrown. This model (used by org.hibernate.test.annotations.cascade.multicircle tests) illustrates the proposed fix: <code> ------------------------------ N G | | 1 | | | | | N | | E N--------------0,1 * F | | 1 N | | | | | | 1 N | * | B * N---1 D * 1------------------ * N N | | | | 1 | | C * 1----- </code> In the diagram: - all associations are bidirectional. - assocations marked with '*' cascade persist, save, merge operations to the associated entities (e.g., B cascades persist to D, but D does not cascade persist to B) If b, c, d, e, f, and g are all transient unsaved that are associated with each other, then when Session.persist( b ) is called, then entities are added to the ActionQueue in the following order: c, d (depends on e), f (depends on d, g), e, b, g Before the fix, entities would be inserted in the same order they were added to the ActionQueue, resulting in an exception when saving d (because d.e is non-nullable and transient) Using the proposed fix, entities will be successfully inserted in the following order: c, e, d, b, g, f In this case, inserting d is delayed until after e is inserted, and inserting f is delayed until after e and g are inserted. Pull Requests: https://github.com/hibernate/hibernate-core/pull/240 (was: https://github.com/hibernate/hibernate-core/pull/240) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Gail Badner commented on HHH-5472: ---------------------------------- This fix will also change the exception thrown when a non-nullable transient reference is not resolved during merge from TransientObjectException to PropertyValueException. This will make exception handling for merge consistent with persist and save. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5472?page=c... ] Steve Ebersole updated HHH-5472: -------------------------------- Pull Requests: https://github.com/hibernate/hibernate-core/pull/240 (was: https://github.com/hibernate/hibernate-core/pull/240) Fix Version/s: (was: 4.0.1) 4.1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-5472?page=com.atlassian.jira.plug... ] Steve Ebersole closed HHH-5472. ------------------------------- Closing for 4.1 release -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira