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
