I agree that we could have a better marker, but I'm just going off the spec at the moment.<div><br></div><div>I've checked the agreed blueprint, and caching in zones is out of scope for Cactus.</div><div><br></div>
<div>Please propose a discussion topic for the Design Summit.</div><div><br><div>Justin<br><br><br><br>
<br><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 12:21 PM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Mar 16, 2011 at 06:47:03PM +0000, Ed Leafe wrote:<br>
> > With our approach to pagination, without caching, the answer is always correct: each query always returns the next {limit} values whose ID is >= {start-id}.<br>
><br>
>       But for this example, you have to traverse *all* the zones in order to get the list of instances for a customer. How else would you define "instances 101-199 of 823 total instances"? How would you know where #101 is?<br>

<br>
</div>The marker should be the canonical zone:instance, so you just query<br>
that zone with instance marker and limit, and move on to the next<br>
zone(s) if your limit is not reached. You never need to build the<br>
full list.<br>
<font color="#888888"><br>
-Eric<br>
</font></blockquote></div><br></div></div>