Hey Ray, I was thinking of just trashing the expenses-gae script because everything now works as intended on GAE with the standard expenses script. Is there another reason for keeping it?

Oh, right, of course. Do you want to make expenses.roo default to GAE and comment out the hypersonic line, or vice versa?

Hi James,

It's a good agile way to solve the problem with making all relationships unowned, this still has a drawback effect of making persistence granular. In fact, users loose the possibility of having dependency inserts and updates made for them by the gae datanucleus framework.
Because it's impossible for roo to guess which fields have to be owned and which don't: it is defined by the business of an app; I personally think spring roo should give the choice of making a field owned or not. The result could be that the app won't work in all cases (when an entity is owned by two entities for example), but if there is a misuse of the user, it is a fair approach to redirect him to the datanucleus documentation (what I mean is that Roo is not responsible for people who are trying to generate code without knowing the framework they target).

I still didn't see what code is generated (since it's a tedious work to grab the git instance, sign it etc...) so this post could be a misunderstanding of the way the fix was made ups sorry if it's the case. I'm looking forward to see the 1.1.1 version.

Best Regards,
Zied Hamdi

Hey Zied, it is not the best solution but it is the solution advocated by the GAE team. The ultimate solution would be GAE supporting unowned relationships. With regards to unowned and owned relationships, it would be difficult for Roo to work out if a particular reference entity was able to exist outside the parent. I would say that an Embedded class (which is how I believe GAE condenses owned relationships under the covers) could be used for this but GWT 2.1.1 doesn't currently support embedded entities.

The other thing that was created during prototyping was a low level datastore implementation using Twig. This worked really well but fell over due to the currently heavy reliance on JPA in our Finder impl, i.e. we return Query objects instead the results of queries.

In any event the current solution meets a happy balance, given the limitations of JPA on GAE.

Should this bug be reopened? It seems that since Roo 1.2.0.RC1 @RooJavaBean no longer generates DataStore relationship sugar!

Since the last time this bug was discussed, DataNucleus 2.0.0.RELEASE has been published which supports unowned relationships with long keys: http://code.google.com/appengine/docs/java/datastore/jpa/overview.html#Using_or_Migrating_to_DataNucleus_2.0

Maybe it DataStore relationship sugar isn't necessary, and Roo can just revert back to using "long" ids instead of "Long"...