[hibernate-issues] [Hibernate-JIRA] Commented: (EJB-409) EAGER fetched collection + Cascade.PERSIST generates broken behavior on session.update

[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-409?page=co... ] Hardy Ferentschik commented on EJB-409: --------------------------------------- According to the persistence spec the following is the semantics of the flush operation (which is called at transaction commit): The semantics of the flush operation, applied to an entity X are as follows: - If X is a managed entity, it is synchronized to the database. * For all entities Y referenced by a relationship from X, if the relationship to Y has been annotated with the cascade element value cascade=PERSIST or cascade=ALL, the persist operation is applied to Y. *For any entity Y referenced by a relationship from X, where the relationship to Y has not been annotated with the cascade element value cascade=PERSIST or cascade=ALL ... Our case we have the first option and hence persist will be applied to the referenced entity. Regarding persisting of entities the spec says further: - If X is a detached object, the EntityExistsException may be thrown when the persist operation is invoked, or the EntityExistsException or another PersistenceException may be thrown at flush or commit time. So really, the problem is that according to the spec a exception should be raised. However, to determine whether the entity is new or detached one would have to do another select which is exactly what merge() does. The semantics of the JPA spec does not allow the usecase given in the testcases. There is of course also the question, why the pure Hibernate testcase behaves differently. We should investigate this. -- 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