Can someone explain _why_ we need caching?<div><br></div><div>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}.</div>
<div><br></div><div>I agree that in practice this means that there's no way to guarantee you get all values while they're changing behind the scenes, but this is a shortcoming of pagination, not caching.  Caching doesn't solve this, it just creates thornier edge cases.  The solution here is a more sensible ordering than 'last modified', and I question the value of pagination (other than for compatibility)</div>
<div><br clear="all">Justin<br><br>---<br><br>Justin Santa Barbara<br>Founder, FathomDB<br><br><br><br>
<br><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 11:14 AM, Andrew Shafer <span dir="ltr"><<a href="mailto:andrew@cloudscaling.com">andrew@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>Global temporal consistency is a myth.</div><div><br></div><div>If you decide not to cache and support pagination then querying every zone for every page is potentially as misleading as caching because what should be on each page could change for every request.</div>

<div><br></div><div>+1 for cache with ttl</div><div><div></div><div class="h5"><div><br></div><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 11:58 AM, Paul Voccio <span dir="ltr"><<a href="mailto:paul.voccio@rackspace.com" target="_blank">paul.voccio@rackspace.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ed,<br>
<br>
I would agree. The caching would go with the design tenet #7: Accept<br>
eventual consistency and use it where it is appropriate.<br>
<br>
If we're ok with accepting that the list may or may not always be up to<br>
date and feel its appropriate, we should be good with the caching.<br>
<br>
pvo<br>
<div><div></div><div><br>
<br>
On 3/16/11 11:45 AM, "Ed Leafe" <<a href="mailto:ed.leafe@rackspace.com" target="_blank">ed.leafe@rackspace.com</a>> wrote:<br>
<br>
>On Mar 16, 2011, at 12:23 PM, Paul Voccio wrote:<br>
><br>
>> Not only is this expensive, but there is no way I can see at the moment<br>
>>to do pagination, which is what makes this really expensive. If someone<br>
>>asked for an entire list of all their instances and it was > 10,000 then<br>
>>I would think they're ok with waiting while that response is gathered<br>
>>and returned. However, since the API spec says we should be able to do<br>
>>pagination, this is where asking each zone for all its children every<br>
>>time gets untenable.<br>
><br>
>    This gets us into the caching issues that were discussed at the last<br>
>summit. We could run the query and then cache the results at the<br>
>endpoint, but this would require accepting some level of staleness of the<br>
>results. The cache would handle the paging, and some sort of TTL would<br>
>have to be established as a balance between performance and staleness.<br>
><br>
><br>
><br>
>-- Ed Leafe<br>
><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br></div>