couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <jch...@gmail.com>
Subject Re: Proposal: Extending immutability
Date Tue, 06 Jan 2009 03:03:47 GMT
On Mon, Jan 5, 2009 at 6:52 PM, Antony Blakey <antony.blakey@gmail.com> wrote:
>> 1. Provide the document rev whenever the id is returned, such as view
>
>> results i.e. not in the document, but in the per-row hash.
>
>
> I meant in the per-row hash *as well*. I'm not suggesting changing anything
> in the document, although the raw document get should return the db UUID,
> and I guess that would need to come as a HTTP header. Bit ugly, and not a
> great API, but as long as the document isn't wrapped, I can't see where else
> to put it.

You could put it in doc._db_uuid.

I think I'm beginning to see what you'd use this for. There are a few
implementation notes.

CouchDB can't tell, without regenerating the view index, whether a
given document update will effect a given key range of the view. So
any query which needed the id and rev in order to determine cache
freshness, would need to update the view.

There is also not currently any facility to query for just the key of
a view's key-value pair. I suppose we could add one but since the
internal cost to CouchDB would be equivalent to a full row lookup
(unless your values are very very large.)

Now - if you were using the views primarily as a translation mechanism
(to reformat documents) but want document-like caching semantics for
those reformatted documents (and lookup by-id works for you), then the
new forms feature may be exactly what you need.

So while the id/rev => doc-state equivalences are interesting (and
handy), I'm still missing the obvious use case for extending them to
view rows.

-- 
Chris Anderson
http://jchris.mfdz.com

Mime
View raw message