couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <>
Subject Re: svn commit: r815984 - in /couchdb/trunk: share/www/script/test/view_include_docs.js src/couchdb/couch_httpd_db.erl src/couchdb/couch_httpd_view.erl
Date Thu, 17 Sep 2009 13:00:13 GMT

On Sep 16, 2009, at 11:51 PM, Paul Davis wrote:
> I don't think I see how this would affect a partitioning scheme. I
> guess it could make people more willing to split documents that might
> be better served as a single doc, but that'd be the same regardless
> with features like multi-key fetch.

Actually, it is the other way around.  The wiki proposal effectively  
uses docid as an entity identifier and would provide advantages to  
designs where an entity and doc are synonymous.  The patch can  
accomplish the same end result, but it doesn't add magic to the JSON.

>> This appears to be better, but it seems to be assigning some magic  
>> behavior
>> to the second argument so it specifies both the value.  Was there  
>> previous
>> discussion or a bug report filed on this that I missed?
> There wasn't a ticket, but the new bit is only a minor tweak to a
> lesser know feature. Using the _rev member of an emitted object comes
> from the ?include_docs=true feature. When I wrote that I fretted over
> the race condition of pulling a doc revision that was different than
> the one that emitted the row. The best answer at the time was "allow
> people to specify a _rev" which was all and good.
> The new bit just extends that slightly.
>> I'm thinking it would be cleaner to support an optional 3 argument  
>> to emit
>> with { _id:"", _rev:"" }?  The current two argument emit() would be  
>> the
>> equivalent of emit(key, value, { _id:doc._id, _rev:doc.rev}).
> I think this is a pretty good idea. Though unless I'm missing
> something the implementation difficulty rises noticeably. The only
> initial drawback I see is how we explain the semantics of default
> behavior. For ?include_docs=true it was simply "current version or
> version specified by _rev". Obviously adding _id makes that weirder,
> but I'm don't see a more clear explanation with the third parameter
> version.
> Paul Davis

In the current code, I don't see how you would emit a string, array or  
other value and also affect the included documents.  If added as a  
third parameter, we could also dispense with using the underscores in  
the argument, so it would really be:

emit(key, value, { id:doc._id, rev:doc._rev});

View raw message