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<[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
