couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CGS <cgsmcml...@gmail.com>
Subject Re: Inlining Linked Document Data
Date Tue, 25 Oct 2011 06:18:45 GMT
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<cgsmcmlxxv@gmail.com>  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
>>
>
>


Mime
View raw message