You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Adam Wolff <aw...@gmail.com> on 2009/04/03 20:32:25 UTC
rev of aggregate results
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.id, 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
Re: rev of aggregate results
Posted by Adam Kocoloski <ko...@apache.org>.
Yes, at the moment that's the case. Changing to iff would be a nice
optimization.
Adam
On Apr 3, 2009, at 10:48 PM, Adam Wolff wrote:
> 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.
>
> A
>
> On Fri, Apr 3, 2009 at 1:27 PM, Adam Wolff <aw...@gmail.com> wrote:
>> Awesome! This is just what I was looking for!
>>
>> A
>>
>> On Fri, Apr 3, 2009 at 1:13 PM, Paul Davis <paul.joseph.davis@gmail.com
>> > wrote:
>>> On Fri, Apr 3, 2009 at 4:04 PM, Adam Wolff <aw...@gmail.com> 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 <paul.joseph.davis@gmail.com
>>>> > 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 <aw...@gmail.com>
>>>>> 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.id, 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
>>>>>>
>>>>>
>>>>
>>>
>>
Re: rev of aggregate results
Posted by Adam Wolff <aw...@gmail.com>.
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.
A
On Fri, Apr 3, 2009 at 1:27 PM, Adam Wolff <aw...@gmail.com> wrote:
> Awesome! This is just what I was looking for!
>
> A
>
> On Fri, Apr 3, 2009 at 1:13 PM, Paul Davis <pa...@gmail.com> wrote:
>> On Fri, Apr 3, 2009 at 4:04 PM, Adam Wolff <aw...@gmail.com> 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 <pa...@gmail.com> 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 <aw...@gmail.com> 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.id, 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
>>>>>
>>>>
>>>
>>
>
Re: rev of aggregate results
Posted by Adam Wolff <aw...@gmail.com>.
Awesome! This is just what I was looking for!
A
On Fri, Apr 3, 2009 at 1:13 PM, Paul Davis <pa...@gmail.com> wrote:
> On Fri, Apr 3, 2009 at 4:04 PM, Adam Wolff <aw...@gmail.com> 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 <pa...@gmail.com> 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 <aw...@gmail.com> 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.id, 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
>>>>
>>>
>>
>
Re: rev of aggregate results
Posted by Paul Davis <pa...@gmail.com>.
On Fri, Apr 3, 2009 at 4:04 PM, Adam Wolff <aw...@gmail.com> 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 <pa...@gmail.com> 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 <aw...@gmail.com> 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.id, 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
>>>
>>
>
Re: rev of aggregate results
Posted by Adam Wolff <aw...@gmail.com>.
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?
A
On Fri, Apr 3, 2009 at 11:59 AM, Paul Davis <pa...@gmail.com> 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 <aw...@gmail.com> 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.id, 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
>>
>
Re: rev of aggregate results
Posted by Paul Davis <pa...@gmail.com>.
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 <aw...@gmail.com> 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.id, 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
>