Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <89c0c52c0705301245w15ad8b94ocbf56d8f6c7fd633@mail.gmail.com>
References: <71A9F153-87F2-44E0-993F-38592037A20F@iq80.com>
 <B7D9D72F-668D-4513-8EE6-5AFE882BD564@iq80.com>
 <89c0c52c0705291150u19efaa5djc6b1589565437b29@mail.gmail.com>
 <72F737AB-CE95-40CC-BC06-22CC9CD08EBA@iq80.com>
 <89c0c52c0705301245w15ad8b94ocbf56d8f6c7fd633@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F1E62099-9C2A-4409-8592-88400C8A2706@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: new-delete-new-find doesn't work
Date: Thu, 31 May 2007 09:17:22 -0700
To: open-jpa-dev@incubator.apache.org

OPENJPA-247

Thanks,

-dain

On May 30, 2007, at 12:45 PM, Kevin Sutter wrote:

> Dain,
> If you've tried these variations, then it sure sounds like a bug.   
> Go ahead
> and create a JIRA report.  Even if we determine an alternate  
> solution or
> answer, at least it will be documented.  Thanks.
>
> Kevin
>
> On 5/29/07, Dain Sundstrom <dain@iq80.com> wrote:
>>
>> 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
>> >>
>> >>
>>
>>