Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 1.1.1.RELEASE
    • Component/s: GAE
    • Labels:
      None

      Description

      Discussion: https://wave.google.com/wave/waveref/googlewave.com/w+FhphtgcaB

      There has been an ongoing discussion of making addon-entity aware of the limitations in Google App Engine's data store, and having it do crafty things to make reference fields work without actually using joins. Let's get a quick wave written up spelling out the plan, and then do it.

        Issue Links

          Activity

          Hide
          James Tyrrell added a comment -

          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?

          Show
          James Tyrrell added a comment - 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?
          Hide
          Ray Ryan added a comment -

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

          Show
          Ray Ryan added a comment - Oh, right, of course. Do you want to make expenses.roo default to GAE and comment out the hypersonic line, or vice versa?
          Hide
          Zied Hamdi added a comment -

          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

          Show
          Zied Hamdi added a comment - 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
          Hide
          James Tyrrell added a comment -

          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.

          Show
          James Tyrrell added a comment - 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.
          Hide
          Stefaan Vanderheyden added a comment -

          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"...

          Show
          Stefaan Vanderheyden added a comment - 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"...

            People

            • Assignee:
              James Tyrrell
              Reporter:
              Ray Ryan
            • Votes:
              7 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: