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 <[email protected]> wrote:
Awesome! This is just what I was looking for!
A
On Fri, Apr 3, 2009 at 1:13 PM, Paul Davis <[email protected]
> wrote:
On Fri, Apr 3, 2009 at 4:04 PM, Adam Wolff <[email protected]> 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 <[email protected]
> 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 <[email protected]>
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