> The behavious of DataNucleus depends on the strategy I choose to generate the > @Id field.
As per the docs for DataNucleus then, which is why I asked you to show your class (and you didn't). If using pessimistic txns then any persist/update/delete will go to the datastore when invoked by the user ... since objects are locked. Hence any identity will be present immediately after the operation. If using optimistic txns any persist/update/delete will go to the datastore at flush/commit. So any identity will be present for all value generators *except* IDENTITY. IDENTITY generators only happen on the persist to the datastore and so cannot be done til the object reaches the datastore. GAE/J also offers SEQUENCE strategy which you could use easily enough. The GAE/J DN plugin is owned by Google and it is in their hands what strategies they offer and what is the default (for their usage). As already said, the JPA spec (and JDO spec also for that matter) say that a user cannot rely on having the identity set until flush() or commit(). Whether some implementations do or not is irrelevant, you cannot rely on it (and those impls could easily change their policy at a later date and still be compliant - and your app would fall apart at that point). There are things that DataNucleus does that Hibernate, EclipseLink etc don't do, but that doesn't mean they should copy us either (whether or not they would be readily capable of such a thing). Writing portable code has to stick to the specs, and developers ought not to pick and choose which bits *they* think are right. A spec is a spec for a reason and it provides a guarantee of behaviour; ignore it at your peril. PS1. EclipseLink is the "reference implementation" for JPA yet that actually means very little. A reference impl is simply a proof of concept demonstrating that the spec can be implemented. In the same way DataNucleus is the "reference implementation" for JDO; doesn't mean that all other JDO impls should copy how we do things. PS2. Strategies of AUTO (JPA) and NATIVE (JDO) don't have to use IDENTITY, and in fact (with DataNucleus) don't since not all RDBMS have such a concept. They use what the implementation decides is most suitable. PS3. You are using a very old version of DataNucleus there (v1.1) since Google haven't updated to a recent version. We write 2.1 now and 2.2 soon. For that reason this forum is not monitored by us -- 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.
