I realise that "non-deterministic" is a relative term, and that given enough time, reading, research, etc etc I will be able to determine why adding a println prevents an NPE. My point (and I think of others) is "why?". Especially since it's taken me 2 days already that I was supposed to have spent working on business logic, not figuring out why mappedsuperclasses misbehave and whether JPA or JDO is the better option.
A GAE app is inherently non-portable to other environments (or at least mine is) so that is of no value. I'm not porting the app. from an existing RDBMS/ORM environment so that isn't a win either. Sure I may have to adjust my code if the datastore API changes, but I can live with that, in fact I'd rather do that than hope that any API changes have been correctly absorbed by the Datanucleus stack. I don't want to appear negative towards Datanucleus, but for my situation it's a sledgehammer to crack a nut On Thu, Sep 24, 2009 at 8:19 AM, datanucleus <[email protected]>wrote: > > > The final straw is:- > > System.out.println("emp.dept name=" + > emp.getDept().getName > > ()); // throws an NPE > > So why not address what the difference is in calls to your persistable > class ? Nothing is non-deterministic by definition that you have a > programming language here and rules are followed (and JDO behaviour is > defined in a spec). Pay particular attention to object states and > fetch groups (and the DataNucleus docs define all you should need to > know around that). > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~----------~----~----~----~------~----~------~--~---
