There are many Use Cases where it makes sense to keep relationships or
you at least want to leverage the power of entity groups even with
JDO. The school-of-thought is a bit different than in other
environments though. While JDO parent to child access is comfortable
it makes not the best use of GAE's massive scalability and performance
advantages. One example:

Say you have a user and all his comments are children in his entity
group. Now in an old school way you would check how many there are is
user.getComments().size() ... well that works but would have to load
the entire array from the store. The new school way of doing this
would be running a query filtered on keys that is an order of
magnitude faster:
http://code.google.com/intl/de-DE/appengine/docs/java/datastore/queriesandindexes.html#Queries_on_Keys
You can always retrieve the parent object (user) because its key is
encoded in any of the child keys.

There are many more examples where you have to think different, but in
general: It makes sense to have entity groups where they persist in
reality: users - comments, users - addresses, bank accounts -
transactions, and so forth...

Hope this helps,
Fred

On 3 Aug., 20:28, Vikas Hazrati <[email protected]> wrote:
> Hi Fred,
>
> Thanks for your response. This is what I suspected too that the entity
> groups might not be able to change. This actually brings me to the
> conclusion that we might not want to keep any owned entities at all.
> We are in the process of converting a legacy application to GAE and in
> the process we have been breaking out relationships due to multiple
> problems. I would write about all the problems that we faced and the
> workarounds and link it here.
> This relationship was probably one of the last bastions that we had
> remaining. With what you mentioned this might have to be broken too
> since a user can move around departments as a valid business case.
>
> So let me ask the community this question, does anyone see the benefit
> of maintaining relations at all? using JPA/JDO. From the complex
> queries that a normal web app would have you would fall into
> situations where you would need to use more and more of unowned
> relationships. Is that true? or am I missing something.
>
> Regards | Vikaswww.inphina.comwww.thoughts.inphina.com
>
> On Aug 3, 10:00 pm, Frederik Pfisterer <[email protected]> wrote:
>
> > You have to use unowned relationships and not place the department and
> > the user in the same entity group. 
> > See:http://code.google.com/intl/de-DE/appengine/docs/java/datastore/relat...
> > use for UserDepartment:
> > private Set<Key> users = new HashSet<Key>();
> > and for User:
> > private Key userDepartmentKey;
>
> > Entity groups cannot be changed once being established.
> > If you want the relationships like you have them, you would have to
> > change the Key of the User object (it's identity) to place it in the
> > entity group of another department, since the department's (parent)
> > key is part of the user key like in a path.
>
> > Cheers,
> > Fred
>
> > On 3 Aug., 15:09, Vikas Hazrati <[email protected]> wrote:
>
> > > Oops I somehow managed to hit the submit without the full question...
> > > Apologies...Let me start again
>
> > > I have 2 entities UserDepartment and User, which are defined as
> > > follows
> > > @Entity
> > > public class UserDepartment extends DomainObject<Long,
> > > UserDepartment>
> > > {
> > >         @Id
> > >         @GeneratedValue(strategy = GenerationType.IDENTITY)
> > >         private Long departmentId;
> > >         @OneToMany(mappedBy = "userDepartment", cascade =
> > > CascadeType.ALL, fetch=FetchType.EAGER)
> > >         private Set<User> users = new HashSet<User>();
>
> > > and
>
> > > @Entity
> > > public class User extends DomainObject<Long, User> {
> > >         @Id
> > >         @GeneratedValue(strategy = GenerationType.IDENTITY)
> > >         @Extension(vendorName = "datanucleus", key = "gae.encoded-pk",
> > > value = "true")
> > >         private String encodedKey;
> > >         @Extension(vendorName = "datanucleus", key = "gae.pk-id",
> > > value = "true")
> > >         private Long userId;
> > >         private String username;
> > >         @ManyToOne(fetch = FetchType.EAGER)
> > >         private UserDepartment userDepartment;
>
> > > As you would notice that UserDepartment is the parent of the User. Now
> > > once I persist the entity group, i want to modify the user so that it
> > > belongs to a different department now.
>
> > > What is the best way to do that?
>
> > > If i remove the UserDepartment from the User and then assign a new
> > > UserDepartment to it then I get into the issue of trying to access
> > > multiple entity groups in the same transaction.
>
> > > Regards | Vikaswww.inphina.com
>
> > > On Aug 3, 6:05 pm, Vikas Hazrati <[email protected]> wrote:
>
> > > > I have 2 entities UserDepartment and User, which are defined as
> > > > follows
>
> > > > @Entity
> > > > public class UserDepartment extends DomainObject<Long, UserDepartment>
> > > > {
>
> > > >         @Id
> > > >         @GeneratedValue(strategy = GenerationType.IDENTITY)
> > > >         private Long departmentId;
>
> > > > and
>
> > > > @Entity
> > > > public class User extends DomainObject<Long, User> {
>
> > > >         @Id
> > > >         @GeneratedValue(strategy = GenerationType.IDENTITY)
> > > >         @Extension(vendorName = "datanucleus", key = "gae.encoded-pk", 
> > > > value
> > > > = "true")
> > > >         private String encodedKey;
>
> > > >         @Extension(vendorName = "datanucleus", key = "gae.pk-id", value 
> > > > =
> > > > "true")
> > > >         private Long userId;
>
> > > >         private String username;
> > > > @ManyToOne(fetch = FetchType.EAGER)
> > > >         private UserDepartment userDepartment;

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

Reply via email to