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 Tue, 25 Oct 2011 21:27:54 GMT
Hi,

No need for going through the database more times than it does
already.  I'm suggesting that it would function exactly the way it
does now, in the functions like all_docs_view_row_obj, (probably
here-ish from what I can make out):

all_docs_view_row_obj(_Db, {{DocId, error}, Value}, _IncludeDocs, _Conflicts) ->
    {[{key, DocId}, {error, Value}]};
all_docs_view_row_obj(Db, {_KeyDocId, DocInfo}, true, Conflicts) ->
    case DocInfo of
    #doc_info{revs = [#rev_info{deleted = true} | _]} ->
        {all_docs_row(DocInfo) ++ [{doc, null}]};
    _ ->
        {all_docs_row(DocInfo) ++ couch_index_util:load_doc(
            Db, DocInfo, if Conflicts -> [conflicts]; true -> [] end)}
    <--- Call here would probably change and all_docs_row() would need
updating, I think.
    end;

I did consider suggesting that follow_links be an integer representing
depth, rather than a simple boolean, but that would involve having to
scan the database for every field to see if it was an ID, so rejected
that idea.  As a simple boolean, we can use the existing {_id: XXXX}
mechanism, there would only be one level of replacements and no
infinite loop (even if it references itself), which is simpler and
faster.

Cheers,

Jamie.

On Wed, Oct 26, 2011 at 06:22, CGS <cgsmcmlxxv@gmail.com> wrote:
> Hi,
>
> Well, for your idea, the map function should go through the database at
> least twice or to use server side document retrieval mechanism. In both
> cases one needs to take care of the infinite loop (to define a certain level
> for inline replacements). Nevertheless, if you think that would be useful,
> ask for that.
>
> Cheers,
> CGS
>
>
>
> On 10/25/2011 09:26 AM, Jamie Talbot wrote:
>>
>> 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<cgsmcmlxxv@gmail.com>  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<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