Hi, I don't really understand what you mean by that, unless you mean like inline macro expansion, in which case, kind of.
I've tried to put a clear example together here[1]. It was hand-typed so excuse any bracket mismatches :) Is it worth putting an issue into JIRA for this, or is it just wishful thinking? :) Cheers, Jamie. [1]: http://pastebin.com/t1A24miB On Tue, Oct 25, 2011 at 16:18, CGS <[email protected]> wrote: > Hi, > > So, I misunderstood. Something like a header file for C/C++. > > Cheers, > CGS > > > > On 10/24/2011 11:19 PM, Jamie Talbot wrote: >> >> Hi, >> >> Not quite. To be clear, this is talking about views, not documents. >> There wouldn't be any duplication of data (at least, not imposed by >> this suggestion). I still propose to emit {_id: XXXX} in a view, but >> instead, when having that view called with follow_links=true, have >> XXXX replaced by the data of the document with id XXXX. When called >> without follow_links=true, you would just return the _id (as it works >> now if you don't include_docs). >> >> Best, >> >> Jamie. >> >> On Mon, Oct 24, 2011 at 23:45, CGS<[email protected]> wrote: >>> >>> Hi, >>> >>> If I understood correctly your idea, you want to make N to M correlations >>> and encapsulate everything in a document. Am I correct? If so, you may >>> run >>> in the following problem. >>> >>> Consider that you created such a document as you suggested (document X={A >>> U >>> B | A -> B}) not thinking that later you may need any set you used >>> there. >>> Later, you want to have document Y={C U B | C -> B}. That will increase >>> your >>> DB unnecessary as you duplicate B. If you use include_docs as it is now, >>> you >>> don't run in such a problem. In addition, you can filter your ancestors >>> even >>> in this format of the linked documents (after all, ancestors is only a >>> key). >>> >>> In my 2c opinion, one has more freedom to implement what he/she needs in >>> this format of linked documents. But this is my 2c opinion and maybe your >>> proposal would really help the community. >>> >>> Cheers, >>> CGS >>> >>> >>> >>> >>> On 10/24/2011 09:29 AM, Jamie Talbot wrote: >>>> >>>> Hi, >>>> >>>> With reference to linked documents, is there any support for the idea >>>> of linked document data being inlined into an emitted {_id: XXX} >>>> block, perhaps with a new query parameter such as 'follow_links=true', >>>> rather than being appended when called with 'include_docs=true'? >>>> >>>> I know this represents a substantial departure from how things work >>>> now, but it would offer two significant benefits that I can see: >>>> >>>> 1) The ability to follow multiple linked docs from a single document >>>> in a single request. Let's say for a blog post: >>>> >>>> function (doc) { >>>> emit(doc.timestamp, [{_id: doc.category_id}, {_id: >>>> doc.user_id}]); >>>> } >>>> >>>> called with follow_links=true which would return for example: >>>> >>>> { >>>> "key": 'POST010', >>>> "value": [{ >>>> '_id': 'CAT001', >>>> 'name': 'First Category' >>>> }, { >>>> '_id': 'USER004', >>>> 'name': 'Monkey Magic', >>>> 'dob': '1981-02-06' >>>> }] >>>> } >>>> >>>> 2) You could combine it with include_docs=true, and be able to >>>> retrieve the source document at the same time. At the moment when >>>> using this, if I want data from the source and the linked doc, I can >>>> only retrieve one or the other with include_docs, which either forces >>>> me to emit more data from the source, increasing the size of the view, >>>> or else avoid using the link and make multiple requests. >>>> >>>> While currently useful for hierarchies, I find the linked docs feature >>>> a little limiting when I want to use it for any other purpose. >>>> >>>> Thoughts? >>>> >>>> Are there any existing ways to achieve the above? >>>> >>>> Cheers, >>>> >>>> Jamie >>>> >>>> --- >>>> http://jamietalbot.com >>> >> >> > > -- --- http://jamietalbot.com
