bump... I think the first time I posted this message, pastebin went offline, but the unit test is back up and visible...
http://pastebin.com/kDw1rX7e What I'd really like to know is whether this test should ever pass, and if not, where can I read about the details of the merge call. If it should pass, that would be interesting as well because I would know to go take it up with the Spring folks. -Wes On Fri, Apr 23, 2010 at 1:57 PM, Wes Wannemacher <[email protected]> wrote: > Hello, I've been lurking on this list for a while and i have been a > happy user for OpenJPA for a year or so. However, I came across a > situation recently which kind of suprised me. > > Imagine that both CDO_ConditionCode and CDO_CageCode are enhanced > entities that do not a relationship. These beans have an @Id field (of > type String) and a description (of type String). Here is the > interesting snippet of a unit test I wrote to check out this behavior > -> > > CDO_ConditionCode retrievedCondCode = em.find(CDO_ConditionCode.class, "00"); > CDO_CageCode retrievedCageCode = em.find(CDO_CageCode.class, "00000"); > > retrievedCondCode.setDescription("new description"); > retrievedCageCode.setDescription("new description"); > > em.getTransaction().begin(); > retrievedCageCode = em.merge(retrievedCageCode); > // em.flush(); // with or without the flush, this test fails > em.getTransaction().commit(); > > CDO_ConditionCode otherRetrievedCondCode = > em.find(CDO_ConditionCode.class, "00"); > assertTrue("expected value not to change", "description of > 00".equals(otherRetrievedCondCode.getDescription())); > > I noticed it while working on an oracle database. I had a breakpoint > in one section of my code and I was trying to figure out an unrelated > problem. While the app was hanging at the breakpoint, I noticed that > changes to an unmerged entity had been written to the database. If you > want to see the full unit test, it will be available here for a little > while - > > http://pastebin.com/kDw1rX7e > > In the application, most of the JPA operations are hidden behind a DAO > that delegates to Spring's JpaTemplate. However, I wrote the unit test > to get rid of the JpaTemplate to see if hte problem was with my DAO, > Spring or OpenJPA. In addition to removing the JpaTemplate, I also ran > the unit test using EclipseLink 2.0.2, which failed at the assert, > just like OpenJPA. That leads me to believe that this isn't > necessarily a *problem*, but it is that maybe I misunderstand the > behavior of a call to merge. Can someone explain to me why this fails, > or just point me to a section that would help me understand why a > merge to one entity causes the other entity to be saved to the > database. Or, if this should succeed, I will look further at Spring > being the culprit (even though I eliminated the JpaTemplate, I did not > eliminate Spring's LocalContainerEntityManagerFactoryBean). > > Thanks guys! > > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote!
