incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Talbot <ja...@jamietalbot.com>
Subject Re: Inlining Linked Document Data
Date Mon, 24 Oct 2011 21:19:51 GMT
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
>
>



-- 
---
http://jamietalbot.com

Mime
View raw message