openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: new-delete-new-find doesn't work
Date Wed, 30 May 2007 00:08:39 GMT
Thanks for taking a look at this.  I tried adding a flush after the  
remove but the test fails at the same location.  I also tried  
commenting out the merge calls, but it fails at the same point.

Any ideas?  Do you think it is a bug?

-dain

On May 29, 2007, at 11:50 AM, Kevin Sutter wrote:

> 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
View raw message