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 22:38:30 GMT
On Mon, Jan 5, 2009 at 17:25, Antony Blakey <> wrote:

> But then you need to get the view value rather than just the row metadata.
> I propose including the rev in the view result row so that it appears even
> if the value doesn't. Furthermore it means that you can write (third-party)
> generic interposition software without requiring that your views have a
> certain value structure.

+1, but see caveat below

I disagree - etags is a property of the transport protocol, and is at the
> wrong granularity. If all but one document in the view result hasn't changed
> then a transparent document cache would have no way of knowing if all of the
> documents have changed or just one. This affects memoization, which isn't
> based on view window requests.

This is what I was saying in my last post. Etags are good (and we should
support them), but they are not very granular in this case.

But I'm suggesting per-document / pre-view-row immutable-value-identity,
> which is quite different than per-view-window caching.

I'm now thinking about what you're saying here, Antony, and I think I might
be starting to agree. I was going to suggest that perhaps generating the
etag based on the _rev of each document included, uuid of database, design
doc seq #, etc might accomplish what you want. However, even though I can't
see a definite use case immediately, I can see the logic behind the
transparency you speak of.

I like it.

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