MountainClimb / datanucleus-appengine

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

@NotPersistent fields set to null when object is detached #189

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Instantiate a PersistenceCapable object with at least one field
annotated with @NotPersistent and persist it.
2. Retrieve the object and assign another object to the @NotPersistent field.
3. Detach the encapsulating object and inspect the value of this field --
it is set to null after the detachment.

My quick test app is zipped and attached. Use /persist to persist a new
Parent object. Then use /get?id=1 to see the error. You can inspect the
console output to verify that the object wasn't null before it was detached.

Note that I've tested this in both the production and deployed environments.

Original issue reported on code.google.com by apijason...@gtempaccount.com on 12 Jan 2010 at 10:07

Attachments:

GoogleCodeExporter commented 8 years ago
Thanks for the report!  The behavior you're seeing makes sense to me because 
you're 
calling pm.detachCopy().  detachCopy() returns a new instance of the original 
object 
containing all Persistent fields that were fetched while the pm was open and 
all fields 
that are in the default fetch group.  detachCopy() has no knowledge of non-
persistent fields, so it seems reasonable that the copy wouldn't contain 
transient 
state.  Let me verify that the rdbms plugin exhibits the same behavior, but I 
suspect 
it will.

As a workaround, there is a way to detach an object without calling detachCopy: 
call 
pm.setDetachAllOnCommit(true).  This will detach your objects in-place rather 
than 
returning a detached copy.

Original comment by max.r...@gmail.com on 12 Jan 2010 at 11:41

GoogleCodeExporter commented 8 years ago
Yeah, rdbms works the same way.  I'm marking as invalid but if you still 
disagree I'm 
happy to continue the debate.

Original comment by max.r...@gmail.com on 12 Jan 2010 at 11:47