This issue is about adding the entity name and id to the exception, so we won't have to add the breakpoint! For all the situations when we've had "An entity copy was already assigned to a different entity." errors, I have been able to fix (/work around) them by setting the breakpoint, checking the entity class name/id, and then modify our application (particularly cascades and merge order). But working with the breakpoint takes extra time, compared to getting all the info in the error message. That is the reason I created the issue, to save time when trying to understand what needs to change in our code.
That being said, there may be bugs in Hibernate that causes this error when it should not (possibly even introduced after this issue was created). However, that would be reason to open another issue, to have those bugs fixed. And to increase the chances, do attach a test case. Even better, provide a patch also.
However, changing when this exception is thrown was never the intention of this issue.
Yes, we can wish the Hibernate team was more responsive in the forum - but that does not mean we don't want the additional exception information as of this issue, does it?
And the more irrelevant comments that are added (like this one...), the less likely that someone from the Hibernate team cares to read and understand that this issue is really just a one line change.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Let me try once more to explain:
This issue is about adding the entity name and id to the exception, so we won't have to add the breakpoint! For all the situations when we've had "An entity copy was already assigned to a different entity." errors, I have been able to fix (/work around) them by setting the breakpoint, checking the entity class name/id, and then modify our application (particularly cascades and merge order). But working with the breakpoint takes extra time, compared to getting all the info in the error message. That is the reason I created the issue, to save time when trying to understand what needs to change in our code.
That being said, there may be bugs in Hibernate that causes this error when it should not (possibly even introduced after this issue was created). However, that would be reason to open another issue, to have those bugs fixed. And to increase the chances, do attach a test case. Even better, provide a patch also.
However, changing when this exception is thrown was never the intention of this issue.
Yes, we can wish the Hibernate team was more responsive in the forum - but that does not mean we don't want the additional exception information as of this issue, does it?
And the more irrelevant comments that are added (like this one...), the less likely that someone from the Hibernate team cares to read and understand that this issue is really just a one line change.