> The behavious of DataNucleus depends on the strategy I choose to generate the 
> @Id field.

Obviously, as per DN docs (and why I asked you to show your class) :-

If using pessimistic txns, then all persist/update/delete operations
happen immediately. Consequently it doesn't matter which value
generator strategy you choose you always get an identity immediately
after the persist.

If using optimistic txns, then all persist/update/delete operations
are queued until flush/commit, so we do them in a block. If you chose
a value generator strategy of IDENTITY then this can only happen
during persist (by definition), so is delayed. If you chose any other
value generator strategy then you get your identity immediately since
it doesn't require a persist.

Google have the opportunity to define their own value generator
strategies in *their plugin*. They also provide "SEQUENCE" strategy
which you could use, and get your identity immediately after a
persist.

At the end of the day the JPA (and JDO too) specs say that no identity
is guaranteed until flush, and anyone writing a portable application
should follow that rule (and not pick and choose what they feel like
following). It doesn't matter if some implementations just happen to
do one thing or another, it is not covered by the spec so you cannot
guarantee it. There are many things that DN does that Hibernate,
EclipseLink and OpenJPA don't do ... but does that mean they should
copy us ? Of course not. Implementors follow a spec for a reason,
because its behaviour is guaranteed.

PS1. Whilst EclipseLink is "Reference Implementation" for JPA, that
actually means very little on its own. It simply means that it is
proof that the spec is implementable. DataNucleus is "Reference
Implementation" for JDO, but doesn't mean that any other JDO impl
should copy how we do things.

PS2. Use of AUTO (JPA) / NATIVE (JDO) is not to use IDENTITY since not
all datastores support such a thing.

PS3. GAE/J's plugin uses such an old version of DataNucleus (we're
currently at version 2.1, whereas you use 1.1) that we don't actually
support any such usage now, hence why I don't monitor this forum, and
only post here when i just happen to have some spare time.

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en.

Reply via email to