On Wed, Feb 15, 2012 at 4:16 PM, stephenp <[email protected]> wrote: > Jeff, > > Thanks for the reply! You've really, really helped. I understand that a > task will have to create a transaction and that it doesn't run in the > context of the transaction that may have enqueued it. A re-phrasing of my > question: > Request 1 -> txn.begin() -> add entity "statistic" to "account" -> > commit() ... where the commit enqueues the next request/task > Request 2 (task) -> txn.begin() -> query "account" for all "statistics" -> > txn.commit() > > It sounds like what you're saying is that as long as "account" and > "statistic" are in the same entity group, then I'll see the added person. > If they're not in the same entity group, then it'll be eventually > consistent, right? In our case, we're using JDO and the relationship > between statistic and account is modeled as a "Key" field, but they aren't > in the same entity group. In "Request 2" we simply query by kind > "statistic" for all statistics with a filter for the current account. We > don't get any error like "ancestor required in transaction". >
Sounds like you're on the right track. If you put account-related statistics in the same entity group as the account entity, you can always do an ancestor query (strongly consistent) to get statistics for the account. This is why it's very important to pick and choose entity group structures on the HRD. It's much more important than it was back in the M/S datastore. BTW there is another "trick" here which you might find useful someday (probably not here). Let's say you have two entities, A and B in different entity groups. Since get-by-key is strongly consistent, if you store a Key<B> in A, you can always get a strongly consistent view of B when you have an A. Last question: does the use of the transaction in Request 2 make any > difference? > None whatsoever, except that it's probably slightly slower (extra rpcs to set up the txn). > As for our app, you can think of it as a finance app with credits and > debits and statistics like "total spent", "average spent", etc. And we roll > up stats so we have a hierarchy of summaries for different periods: weeks, > months, years, all years. We currently kick off tasks to recalculate stat > summaries whenever a credit or debit is added. Call it "near-realtime". > When the user navigates to the "all-years" page we've likely recalculated > the hierarchy of stat summaries. We don't really want to wait for them to > request this page to go try and calculate all the summaries because it > could be a long wait. I also wasn't too fond of having a cron job every > minute looking for changes, but maybe that's what I need to do. > Assuming you generate the statistics for each account linearly (ie, not firing off a dozen parallel tasks to add up the data for a single account), it sounds like putting statistics in the same entity group as Account is the ideal solution. Jeff -- 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.
