incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Wolff <>
Subject Re: rev of aggregate results
Date Fri, 03 Apr 2009 20:27:33 GMT
Awesome! This is just what I was looking for!


On Fri, Apr 3, 2009 at 1:13 PM, Paul Davis <> wrote:
> On Fri, Apr 3, 2009 at 4:04 PM, Adam Wolff <> wrote:
>> Oh, I'm not concerned that I'm not seeing the most recent info -- just
>> wondering what's the fastest way to find out if the application has
>> the most recent data.
>> Tell me more about "view tags." That may be exactly what I'm looking
>> for. Is that an ETAG for the view results?
> Exactly. I should've been more specific. Also, it looks like etags are
> already in.
>> A
>> On Fri, Apr 3, 2009 at 11:59 AM, Paul Davis <> wrote:
>>> Maybe I'm missing something, but assuming you're not using the
>>> stale=ok flag you should be guaranteed that the view you're seeing is
>>> the most recently completed update after your request was received.
>>> Ie, it'll wait if the view is being updated.
>>> If view tags are in trunk that'd capture the information on the state
>>> of the btree. I'm not sure if that patch has made it in yet though.
>>> Or I could be way off base with what you're asking.
>>> HTH,
>>> Paul Davis
>>> On Fri, Apr 3, 2009 at 2:32 PM, Adam Wolff <> wrote:
>>>> Hi,
>>>> I've noticed a pattern that appears in a couple of places in our app.
>>>> We have views which return multiple documents for a given key. What's
>>>> the fastest way that we can determine if we have the current rev of
>>>> the view, if we define a view's rev as the id and revs of all the
>>>> documents in the view?
>>>> The solution I've thought of so far is to write the view's map
>>>> function like this:
>>>> map : function(doc){
>>>>   var key = computeKey(doc);
>>>>   emit([key,, doc.rev], null);
>>>> }
>>>> We query the view with startkey=[key, null, null]&endkey=[key, {}, {}]
>>>> and the rev for that key is just the text of the response. We haven't
>>>> gotten all the way through this, but it sees like it should work. My
>>>> concern is that this string will get unwieldy when there are a lot of
>>>> docs in the result set.
>>>> Is there a recipe for determining the rev of a document collection?
>>>> Something in the semantics of id or rev that I've missed?
>>>> Thanks in advance,
>>>> Adam

View raw message