On 06/01/2009, at 1:33 PM, Chris Anderson wrote:
You could put it in doc._db_uuid.
But it's not a document property - it qualifies the id/rev within a value space, but it shouldn't travel with the document because it's a function of which replica you happened to retrieve it from.
OTOH, I guess you could make it such that it is ignored by the db when writing, and inserted when returning the document. And maybe as a "where did I get this value from" it may have some as-yet-unforeseen usefulness.
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.
Currently the view machinery supplies the id of the document for each row. I don't understand why it can't supply the rev of the document that was passed to map().
And the view machinery already tracks updates to design documents, so storing the rev of the design document in the view structure shouldn't be hard.
I must be misunderstanding something - I'm afraid your subsequent email hasn't made it clearer to me.
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.)
A parallel to include_docs=false. Actually, this isn't *so* important to me - my concern is that by having the rev reliably in the result row with the id so that generic machinery can act on view results independently of the map function.
So while the id/rev => doc-state equivalences are interesting (and handy)
Much handier if made globally unique with the db uuid.
, I'm still missing the obvious use case for extending them to view rows.
Completeness. IMO this is a simple change that has significant conceptual weight i.e. the idea of the universe of all Couch instances holding hierarchic sequences of uniquely identifiable immutable values.
I must admit I'm not up on the form implementation, but I suggest that anything that maps documents should include enough system-provided meta-information to construct the global key for the constituent values.
I know the obvious use-case is caching, and one response is to rely on Couch's HTTP-based caching, but this change would allow not only more extensive caching independent of Couch's API model i.e value-tracing forms such as memoization, but IMO will also prove to have other benefits. It's a clean theoretical idea.
Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The difference between ordinary and extraordinary is that little extra.
