On Wed, Sep 16, 2009 at 10:26 PM, Curt Arnold <[email protected]> wrote:
>
> On Sep 16, 2009, at 5:42 PM, Chris Anderson wrote:
>
>> On Wed, Sep 16, 2009 at 3:04 PM, <[email protected]> wrote:
>>>
>>> Author: jchris
>>> Date: Wed Sep 16 22:04:18 2009
>>> New Revision: 815984
>>>
>>> URL: http://svn.apache.org/viewvc?rev=815984&view=rev
>>> Log:
>>> include_docs now take an _id (as well as a _rev) in the emitted value, to
>>> load docs other than the one doing the emitting. This means you can have one
>>> doc list a set of other docs to load in a single query. Enjoy!
>>>
>>
>> In Governator voice: "It's not a JOIN."
>>
>> But you can use it if you have a doc like:
>>
>> {"_id":"my-outline",
>> "other_docs":["docid,"other-docid"]
>> }
>>
>> and then a view like
>>
>> function(doc) {
>> for (var i=0; i < doc.other_docs.length; i++) {
>> emit([doc._id, i], {"_id" : doc.other_docs[i]}
>> };
>> }
>>
>> and then you will have an ordered list of the other docs available in
>> a view query (with include_docs) You can also specify the other docs
>> _rev if you want -- if it's not available it comes up as null in the
>> feed.
>>
>> Of course, the usual include_docs performance caveats apply, but this
>> time we get a feature out of it!
>>
>> Chris
>>
>
>
> I'm thinking that this may be sufficient to address the use case described
> in http://wiki.apache.org/couchdb/Forward_document_references. I was uneasy
> about that proposal since it strongly favored using one document per entity
> when that model may not be the appropriate partitioning scheme, but I never
> bothered putting my thoughts down since it looked like it wasn't going any
> where fast.
>
I don't believe I've ever seen that wiki page before. Which is odd
because I watch all wiki edits to try and keep abreast of exactly this
sort of thing.
I would say yes, Chris's patch addresses almost this exactly though.
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.
> 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
