Closed GoogleCodeExporter closed 8 years ago
This is my User file's JDO-related info:
...
@PersistenceCapable(detachable = "true")
@Inheritance(strategy = InheritanceStrategy.UNSPECIFIED)
@Discriminator(strategy=DiscriminatorStrategy.UNSPECIFIED)
abstract public class User {
...
}
This is Staffer class:
...
@PersistenceCapable(detachable = "true")
@DatastoreIdentity
public class Staffer extends User {
@Persistent
private String nickname;
/**
* @return the nickname
*/
public String getNickname() {
return nickname;
}
/**
* @param nickname the nickname to set
*/
public void setNickname( String nickname ) {
this.nickname = nickname;
}
}
Original comment by spa.yu...@gmail.com
on 4 Feb 2012 at 7:00
This is how I update the staffer into DB (same as ucs.persist(), which has this
call below)
...
obj = pm.makePersistent( obj );
...
Original comment by spa.yu...@gmail.com
on 4 Feb 2012 at 7:01
This is PK specification for User. Staffer has no additional PK spec, as it
inherits the key from the User.
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
@Extension(vendorName = "datanucleus", key = "gae.encoded-pk", value = "true")
private String key;
Original comment by spa.yu...@gmail.com
on 4 Feb 2012 at 7:13
Staffer extends User, where User is using application-identity, and Staffer
wants to user datastore-identity ? Really ? Please read the JDO spec; you have
one id type or another in an inheritance hierarchy.
You present some persistence code referring to various objects yet the majority
of these objects are obviously nothing related to your problem; if you think
there is some problem with inherited objects and updating fields in the derived
class then you present those classes ... completely, and only those, and the
persistence code ought to only refer to those. You say you have some problem
yet don't identify the line in the persistence code where that problem comes in.
You make no reference to the log, yet the log would obviously tell you what is
happening at every step. I'd look at that if I was you
What is "runtime" ? you mean when deployed on GAE? in which case it isn't a
problem with the GAE DN plugin, but a problem for GAE as a whole.
GAE tests update fields in base and subclasses and have no problem. Either
provide a complete testcase that demonstrates something. Nontransactional
updates are not atomic, so you either have to wait for PM.close, or commit a
transaction for the updates to go to the DB.
Original comment by googleco...@yahoo.co.uk
on 4 Feb 2012 at 11:41
Andy, it is a bug, even though I cannot replicate it when running local tests.
Here is a link to exact same issue others are having, and it includes a
solution. The problem is with subclass fields not being marked dirty, or so it
appears because when I do JDOHelper.makeDirty(obj, "nickname"), it works, when
I don't - it doesn't. Please see this link, it has a lot more details.
http://stackoverflow.com/questions/7486710/updating-objects-in-gae
Original comment by spa.yu...@gmail.com
on 6 Feb 2012 at 5:07
//my code
staffer.setNickname( "newValue" );
JDOHelper.makeDirty( staffer, "nickname" );//this makes or breaks the code - if
it is enabled, all is well, if commented out - nickname doesn't get saved. This
issue exists only for subclasses, and I DID fix the app vs datastore identity,
it doesn't change the result.
pm.makePersistent( staffer );
pm.close();
pm = pmFactory.getPersistenceManager();
Query q = new Query( "select from my.Staffer" );
List<Staffer> list = (List<Staffer>)q.execute();
list.get( 0 ).getNickname();//it is still "oldValue"
Original comment by spa.yu...@gmail.com
on 6 Feb 2012 at 5:15
That stackoverflow case is someone wanting to update something generically, so
was using reflection - and as they say in that case ... they can read an object
in and update fields successfully ... just need it done in a generic way. I see
no reflection in your case, hence different. That person was using v1 of the
plugin, you aren't.
Whatever, a case being non-reproducable (in local store) means low priority
(unless Google want to look at it of course). You have the log as a clear way
of debugging your problem (because it tells you objects states and lots more
after each operation) ... if you choose to do it.
Original comment by googleco...@yahoo.co.uk
on 6 Feb 2012 at 6:56
Can't reproduce no matter how hard I try.
Original comment by googleco...@yahoo.co.uk
on 4 Jun 2012 at 10:29
Original issue reported on code.google.com by
spa.yu...@gmail.com
on 4 Feb 2012 at 6:57Attachments: