MountainClimb / datanucleus-appengine

Automatically exported from code.google.com/p/datanucleus-appengine
0 stars 0 forks source link

Cannot delete detached object outside a txn (JPA) #142

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Datanucleus ignores the request when trying to remove a detached object
that was just retrieved from the database:

@Entity
public class Vote {

    @Id 
    private Key id;

}

Attempt of removing this entity using JPA results in:

18:14:31,370 DEBUG [Persistence] Deleting object from persistence :
"com.acme.Vote@40d6e551"
18:14:31,370 DEBUG [Lifecycle] Object "com.acme.Vote@40d6e551"
(id="org.datanucleus.identity.IdentityReference@138ada25") has a lifecycle
change : "P_NEW"->"P_NEW_DELETED"

Original issue reported on code.google.com by icol...@gmail.com on 9 Oct 2009 at 4:20

GoogleCodeExporter commented 8 years ago
So where does it say that this is "ignored" ? The object is dirty and in deleted
state. So flush it to the datastore. Perhaps if you also provided your 
persistence
code then Google would be able to see what you are doing.

Original comment by googleco...@yahoo.co.uk on 10 Oct 2009 at 8:49

GoogleCodeExporter commented 8 years ago
The previous log was produced by a transaction-less code executed from a junit 
test.
The deletion was not being flushed to the database. I wish I could provide some
testing code, but we have already reimplemented the deletion using 
DatastoreService
and moved on. If Google is not able to reproduce, please feel free to close it.

Original comment by icol...@gmail.com on 13 Oct 2009 at 8:47

GoogleCodeExporter commented 8 years ago
I wrote 4 new tests to try and reproduce the behavior you're reporting:
1) Delete a detached instance with a txn
2) Delete a detached instance without a txn
3) Create and delete an instance inside the same txn
4) Create and delete an instance without a txn but using the same persistence 
manager.

All 4 tests pass for me.  The state transition from P_NEW to P_NEW_DELETED 
indicates
to me that you were doing some flavor of number 4, but without your code I 
can't dig
any further.  Closing for now, but if you encounter this again please free to 
reopen
with more info.

Original comment by max.r...@gmail.com on 13 Oct 2009 at 2:24

GoogleCodeExporter commented 8 years ago
I take it back.  I wrote all my tests in JDO originally but when I wrote the JPA
versions, test 2 failed.  You can actually see the bad behavior with this tiny 
program:

@Entity
public class Vote {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;

  public Long getId() {
    return id;
  }
}

  static public void main(String[] args) {
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("blar");
    EntityManager em = emf.createEntityManager();
    Vote pojo = new Vote();
    em.persist(pojo);
    em.close();
    expectState(ObjectState.DETACHED_CLEAN, pojo);
    em = emf.createEntityManager();
    pojo = em.find(pojo.getClass(), pojo.getId());
    expectState(ObjectState.HOLLOW_PERSISTENT_NONTRANSACTIONAL, pojo);
    em.close();
    em = emf.createEntityManager();
    pojo = em.merge(pojo);
    expectState(ObjectState.HOLLOW_PERSISTENT_NONTRANSACTIONAL, pojo); // boom!
  }

For some reason merge() is transitioning the detached object into the 
persistent-new
state.  I'll see if I can reproduce this with a DataNucleus trunk build and if 
so
I'll file a DataNucleus bug.  Thanks for the report!

Max

Original comment by max.r...@gmail.com on 13 Oct 2009 at 3:01

GoogleCodeExporter commented 8 years ago

Original comment by max.r...@gmail.com on 13 Oct 2009 at 3:01

GoogleCodeExporter commented 8 years ago
My test passes against Datanucles 2.0.0 m2.  We won't be upgrading to this for 
awhile
unfortunately.  I'm adding the upgrade bug as a blocker for this.

Original comment by max.r...@gmail.com on 13 Oct 2009 at 5:24

GoogleCodeExporter commented 8 years ago
SVN trunk uses DN3 and don't see this

Original comment by googleco...@yahoo.co.uk on 12 Jul 2011 at 6:07