openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Wannemacher <w...@wantii.com>
Subject Does merging cause all "dirty" entities to be written to the database?
Date Fri, 23 Apr 2010 17:57:32 GMT
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!

Mime
View raw message