On Mon, Jan 5, 2009 at 6:52 PM, Antony Blakey <[email protected]> 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
