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 Sat, 04 Apr 2009 02:48:43 GMT
Shoot nope -- I'm looking for a value that change if *and only if* the
map values have changed. Looks like the ETAG changes whenever anything
changes in the whole database.


On Fri, Apr 3, 2009 at 1:27 PM, Adam Wolff <> wrote:
> Awesome! This is just what I was looking for!
> A
> 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 <>
>>>> 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