openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Wannemacher <w...@wantii.com>
Subject Re: Does merging cause all "dirty" entities to be written to the database?
Date Tue, 27 Apr 2010 13:11:24 GMT
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 <wesw@wantii.com> 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!

Mime
View raw message