couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds" <>
Subject Re: Proposal: Extending immutability
Date Mon, 05 Jan 2009 21:49:56 GMT
> I've mentioned this before, but I'll restate what I think the
> necessary inputs to an Etag generation function are:
> The view function(s) source code.

The _rev of the design doc makes more sense to my brain. Is there a
technical argument either way? I don't immediately see one.

> The seq # of the last db-update that changed the view index. This
> should be somewhat straightforward to pull from the view index. Until
> we are able to do that, we can get by with the current DB seq # at a
> loss of cache efficiency.

I think there might be some extra cache-ability to be obtained by including
the _rev in the the view result rows. For example, this seq number would
change when a new document is indexed by the view but a particular
[startkey,endkey] request might not include that document. In the case of a
straight map without reduce we would have a different etag but not really a
different result.

Is there a way we can get more fine-grained cache efficiency here? There
might be complications with reduce (I'll try to think through it more). If
this is the case then maybe this is not a priority for Couch. If an
individual application knows that this sort of check with _rev on each
document allows for some extra client-side caching without negative side
effects maybe it should be left to the application.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message