Hello Phil, Anyone correct me if I'm wrong but you use one of the following options, among others.
You can have a "User" model, with a "items" ListProperty. The pros: if you have the key for the user (e.g. you can use the email), then with a simple get (faster than a query) you can retrieve the entity including the items. Writing a new object is transactional. The cons: you must always get a set the entire user entity. The entity might get large if there are a lot of items. If you use custom indexes with the "items" property the index might get large quickly, especially if you use more than one ListProperty (exploding indexes). You can have a "User" model, and a "UserItem" whose parent is the User, making it part of a transaction group. Cons: you have limited QPS writes to the transaction group (about 1-10 QPS), but that's the same limitation you have to a standalone User with items. You have to query (seek) the items, although I wouldn't call that a problem without profile data. Pros: you can write individual UserItems. You can have transactions for the user and the items s/he has. You can have a "User" model and a "UserItem" with a User key reference. Cons: you can no longer have a transaction depending on the user and the items s/he has. Pros: you can write individual items without write collisions to the User. You can have a "User" and a flat list (e.g. text, non-indexed) of the corresponding items. Cons: limits the queries you can make, have to update all items at once. Pros: better index performance. Etc. I hope it was helpful and correct? Best regards, Luís -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
