XG transactions will have no effect on global queries, as the fundamental problems still remains (namely that it is impossible to know what entity groups will/should appear in a global query). Additionally you should not use this read_policy, it has little effect in M/S and no effect in HRD.
On Wed, Oct 5, 2011 at 11:04 PM, Beech Horn <beechh...@gmail.com> wrote: > With the advent of XG, will APPLY_ALL_JOBS_CONSISTENCY now work with > non-ancestor groups? > > APPLY_ALL_JOBS_CONSISTENCY = 2 > > """A read consistency that aggressively tries to find write jobs to > apply. > > Use of this read policy is strongly discouraged. > This read_policy tends to be more costly and is only useful in a few > specific > cases. It is equivalent to splitting a request by entity group and > wrapping > each batch in a separate transaction. Cannot be used with non-ancestor > queries. > """ > > -- > You received this message because you are subscribed to the Google Groups > "google-appengine-python" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine-python/-/wAh2LQWixZQJ. > > To post to this group, send email to > google-appengine-pyt...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine-python+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine-python?hl=en. > -- 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-appengine@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.
