On Jun 29, 8:41 am, Phil <[email protected]> wrote: > It sounds like the list property can't be appended to without a > transaction? If so, it seems it'll be better to create two tables, > one for Users and one for Items.
The list property can be appended without an explicit transaction. It just might not be wise, since between a read of the entity and the write with the appended list another request can update the entity, and that update would be lost. The entity write itself is atomic though. You won't have some of the properties written from the original request and some written from the other concurrent request. So just be careful of race conditions, if you can be sure there aren't concurrent requests or that they are idempotent then I guess you should be OK without a transaction. > Just to answer the above questions... I expect many reads of the data > and few writes. I also expect the normal case to have few items (1-2 > on avg) and it won't change often. The key to the Items table would > be user_id-item_name. Are prefix scans in GQL efficient? Also, in > terms of data I'm storing about the items, I have ~5-10 fields of > metadata. If you know the key then that's the fastest way to retrieve the entity, instead of using a query. I don't know the Java syntax by heart, but it's easy to find. > For now I'm assuming that the right thing to do here is to split the > data between tables. Even if it seems to be an unlikely problem now, > I don't want to put myself in a situation where I'm limited by the QPS > that transactions can support. Someone more experienced might be able to elucidate, but on your scenario I don't know what you'd gain with that, other than smaller RPC requests for writing to the user items (at least performance-wise, but it might be a cleaner design). If you have to make a transaction then the User and UserItems must be part of a transaction group (items have the user as a parent), so the transaction locks out the entire group anyway. That's the same as locking out a group made of a single entity, a user with a list of items property. See if you can avoid transactions with your design, if you ever run into write performance problems. -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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?hl=en.
