openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: new-delete-new-find doesn't work
Date Tue, 29 May 2007 18:50:21 GMT
Hi Dain,
Your nudge worked...  I noticed your append last week, but didn't act on
it.  If I remember correctly, I think there are some nuances with our
merge() processing.  From what I can tell, your example doesn't explicitly
require the merge() invocations (although they shouldn't hurt).  I have a
few inline comments below...  I haven't tried your specific example yet,
just some observations...  Thanks.

Kevin

On 5/29/07, Dain Sundstrom <dain@iq80.com> wrote:
>
> ^nudge
>
> -dain
>
> On May 24, 2007, at 8:13 PM, Dain Sundstrom wrote:
>
> > I have a piece of code that effectively does the same thing the
> > following test does:
> >
> >     private void newDeleteNew() throws Exception {
> >         beginTx();
> >
> >         // Create new
> >         Person dain = new Person();
> >         dain.setName("dain");
> >         assertFalse(entityManager.contains(dain));
> >         entityManager.persist(dain);
> >         entityManager.flush();
> >         dain = entityManager.merge(dain);


This merge() call should not be required since you have already done the
persist().

>         assertTrue(entityManager.contains(dain));
> >
> >         // Find and verify
> >         dain = entityManager.find(Person.class, "dain");
> >         assertNotNull(dain);
> >         assertEquals("dain", dain.getName());
> >
> >         // Delete
> >         entityManager.remove(dain);
> >         assertFalse(entityManager.contains(dain));


This part confused me.  A remove() shouldn't remove the entity from the
persistence context.  Also, does your example run any differently if you do
a flush() after the remove()?

>
> >         // Recreate
> >         dain = new Person();
> >         dain.setName("dain");
> >         assertFalse(entityManager.contains(dain));
> >         entityManager.persist(dain);
> >         entityManager.flush();
> >         dain = entityManager.merge(dain);


Here again, there should be no need for the merge()...

>         assertTrue(entityManager.contains(dain));
> >
> >         // Find and verify
> >         dain = entityManager.find(Person.class, "dain");
> >         assertNotNull(dain); // <<<<<<< FAILS


Even with the above comments, this failure confuses me.  Since we have
persisted and flushed the "dain" object, we should be able to find it...

The only thing that I wonder about is that since you didn't do the flush
after the remove, then it's processing the persist first and then the remove
operation.  But, according to section 3.2.1 of the JPA spec, it says that if
persist() is invoked on a removed entity, it becomes managed.  I can't find
a reference in the spec that indicates the order of the operations at
commit/flush time.

>         assertEquals("dain", dain.getName());
> >
> >         commitTx();
> >     }
> >
> > The test fails at the marked point, because the entityManager seems
> > to think the "dain" entity is still deleted.  I assume this type of
> > code would work.  Is this a bug or is my assumption wrong?
> >
> > BTW, I'm using 0.9.8-incubating-SNAPSHOT
> >
> > And here is my entity class:
> >
> > @Entity
> > public class Person {
> >     private String name;
> >
> >     @Id
> >     public String getName() {
> >         return name;
> >     }
> >
> >     public void setName(String name) {
> >         this.name = name;
> >     }
> > }
> >
> > Thanks,
> >
> > -dain
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message