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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>
>>
