On Thu, Sep 17, 2009 at 6:54 PM, Chris Anderson <[email protected]> wrote: > On Thu, Sep 17, 2009 at 9:08 AM, Paul Davis <[email protected]> > wrote: >> On Thu, Sep 17, 2009 at 11:58 AM, Chris Anderson <[email protected]> wrote: >>> On Thu, Sep 17, 2009 at 7:11 AM, Curt Arnold <[email protected]> wrote: >>>> >>>> On Sep 16, 2009, at 11:51 PM, Paul Davis wrote: >>>>>>> >>>>>>> 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]} >>>>>>> }; >>>>>>> } >>>> >>>> >>>> So if I do, >>>> >>>> emit(key, doc) >>>> >>>> am I specifying the key value and overriding the default document to be >>>> included since the value would contain _id and _rev members? They'd have >>>> the same value, so it wouldn't be detectable, but still no clear boundary >>>> between the value parts of the parameter and the document part of the >>>> parameter. >>>> >>>> >>>>> >>>>>> 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 >>>> >>>> >>>> A three parameter version would also allow like: >>>> >>>> emit(key, value, null); >>>> >>>> when you intentionally do not want any documents provided if the user >>>> specifies include_docs=true. >>>> >>>> >>> >>> I don't see a use case for the 3 parameter version. >>> >> >> I think its more about having a clean API. Using members on the value >> does confuse the semantics quite a bit. Pragmatically though, it >> wouldn't really change the end result. >> >>> If you are writing a view to take advantage of the linking feature, >>> you would know that you are working to specify the linked doc _id and >>> perhaps _rev in the value. >>> >>> If you aren't planning on using include docs, or just want the normal >>> version of the feature, (include the doc that emitted) then you can >>> just ignore the whole thing. >>> >>> Generally I'm leaning strongly toward keep-it-super-simple, as >>> anything that a user wants to do is possible with the API as it >>> exists. (If you want to emit a full doc but link to another, you can >>> stick the emitted doc in an envelope.) >>> >>> Chris >>> >>> >>> >>> -- >>> Chris Anderson >>> http://jchrisa.net >>> http://couch.io >>> >> >> While the third parameter option is definitely cleaner in terms of API >> design, I would have to agree that the cost in terms of added >> implementation complexity is a bit forbidding. For the moment without >> attempting the implementation I'd leave it as is, but would be in >> favor of the three parameter version if someone provides a patch. >> >> Specifically, the added complexity is going to come from how the third >> parameter is stored in the btree, how it affects sorting semantics, >> and how it relates to reductions. And that's just off the top of my >> head without trying to write the code. >> > > Yeah let's just punt on that, I don't see any value there. If people > are getting concerned about semantics I'd be fine suggesting we change > the whole thing to be emit(key, {"foo":"bar", "_include_doc" : {"_id" > : "X", "_rev":"1-abc"}}) but that just seems gratuitous and > overthought. >
There's plenty of value to adding it. Its just that there's also plenty of complexity. I may or may not take a crack at implementing it, but for now I agree that its not a priority. >> Paul Davis >> > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io >
