On Mon, Jan 5, 2009 at 7:30 PM, Antony Blakey <[email protected]> wrote: > > On 06/01/2009, at 1:33 PM, Chris Anderson wrote: > >> You could put it in doc._db_uuid. > > 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.
That actually sounds kinda relaxing. :) > 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(). I think it could easily do that. I'm just trying to understand better what good could come of it. > - 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. > OK I'm picturing a use case - for instance an external implementation of reduce, which wants to be able to tell, by passing a key range query through to couchdb, if it needs to recalculate it's external reduction value for that range. Functionally this is the same as per-key-range etags (which the current view infrastructure doesn't provide, because it would have to run the full view query in order to provide them). I can see that for an external indexer, such key-range etags could be of real utility, even if they aren't particularly helpful to CouchDB itself. Also, it does seem that the easiest way to calculate such an etag is by having the view range in question available in the external indexer. Eg - the indexer will have to query couchdb's map-view to see if it has to recalculate a portion of it's result. Again, I'm not sure that having the rev available on the view row makes a difference. The indexer cares about the keys and values, if they've changed, they've changed. >> So while the id/rev => doc-state equivalences are interesting (and >> handy) > > Much handier if made globally unique with the db uuid. > I mostly agree. The first gotcha I can see for the db uuid, is that for a cluster, which we want to be a single logical db, even if there are many nodes involved, would it be better to have a uuid per physical couch instance, or a single uuid for the cluster? >> , I'm still missing the obvious use case for extending them to >> view rows. > > Completeness. ... It's a > clean theoretical idea. > Believe me I appreciate the notion of being able to treat id/rev/db-uuids tuples as canonical. I'm still having a hard time coming up with a concrete use case that can't be accomplished without them. I've been around Couch long enough to know that the things that are "missing" from CouchDB are often missing for a reason. I can't say whether this is one of those cases. I'm still curious for the killer app this feature enables. -- Chris Anderson http://jchris.mfdz.com
