[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-409?page=co... ] Markus Merder commented on EJB-409: ----------------------------------- The problem also occurs if you map contacts as lazy: You have to load customer, load the collection then detach the graph. So it is not dependent on eager loading, but only on whether the collection is initialized or not. -- 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/EJB-409?page=co... ] Hardy Ferentschik commented on EJB-409: --------------------------------------- I don't know yet why this does not work, but I am just wondering why the test case is using the underlying Hibernate Session to refresh the entity? Using the entity manager refresh() or merge() methods works just fine. I know there are sometimes reasons to go to the underlying Hibernate Session, but I am not so sure why you would do that for re-attaching an entity. -- 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/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

[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-409?page=co... ] Markus Merder commented on EJB-409: ----------------------------------- I think, our case is slightly different. In our case X is a detached entity, we do not call persist on X, but update. However, I can understand that you could even argue that specs are complied. So is this issue not going to be fixed? -- 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/EJB-409?page=co... ] Markus Merder commented on EJB-409: ----------------------------------- Anthony, You and me know, that our customer have "special" requirements. ;-) They want to spare db-hits whenever possible, because of cost-reasons. Well, I guess, the solution for them will be not to use Cascade.PERSIST but cascade manually. -- 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/EJB-409?page=co... ] Hardy Ferentschik commented on EJB-409: --------------------------------------- BTW, if it is really that important to save this particular db hit you have to remove CascadeType.PERSIST. -- 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/EJB-409?page=co... ] Markus Merder commented on EJB-409: ----------------------------------- Well, if you use @GeneratedValue to set the id, hibernate can determine if an entity is newly created or just detached. Why is the persist-operation cascaded to detached objects even if it is known that they are detached (you will get a "PersistentObjectException: detached entity passed to persist", when using @GeneratedValue). Don't you think this could be improved? I think this solution (only persisting new objects on flush) would still be according the specs, wouldn't it? -- 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/EJB-409?page=co... ] Markus Merder commented on EJB-409: ----------------------------------- Hardy, did you rename this issue based on my last comment? I think it would be better to open a new issue (or relate to EJB-382) leave the description as it was and optionally mark it as won't fix, because the main discussion was about entities which have no unsaved-value (@GeneratedValue) and thus cannot be determined as detached. Leaving it as it is could avoid future discussions relating the same issue. And what do you think about my suggestion not to cascade persist to detached objects? Regards, Markus -- 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/EJB-409?page=co... ] Markus Merder commented on EJB-409: ----------------------------------- I found out another interesting thing. Anthony said: "- works with 100% plain hibernate (mapping files + session APIs (via session Factory, see test based on hb core template) - fails with 50% plain hibernate (mapping files + EM APIs to obtain HB session)" Actually it also works fine with "60%" plain hibernate: if you use hibernate-xml-mapping files + EntityManager (JPA). So do you think this is breaking the spec as I am using JPA with hibernate mapping files? -- 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