couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giovanni P <>
Subject Re: Humble feature proposal: a little hierarchy solution with `_parent` field and parents passed to mapfun
Date Thu, 12 Jun 2014 18:36:39 GMT
Yes, in no way providing _rev could work. I thought about it, but it would
be very unpractical and bad for various reasons. About the map functions
producing always the same result given the same document, I never thought
it was a principle of CouchDB, it always seemed to me as something that
simplified and made it more robust, but yes, it may be that way because
"map" is supposed to be that way. Nevertheless there is still Math.random.

On Thu, Jun 12, 2014 at 2:42 PM, Ryan Ramage <> wrote:

> On the surface this proposal sounds appealing, but it has some major flaws.
> One key principle of couch's map reduce is that map functions must be
> referentially transparent. Given the same input document, it must produce
> the same result.
> The linkage you suggest would break this principle. The other document
> could be at a different revision than you imagine it to be, or be changing.
> The id itself does not describe the state of the input document. The only
> way it might work is if you provide an _id and a _rev as a link but I still
> would not recommend going down this path. It is of a single couchdb
> instance. You can imagine scenarios where filtered replications dont
> replicate parent docs. In a multi-couch environment and with replication
> trying to manage related docs does not scale.
> On Thu, Jun 12, 2014 at 7:40 AM, Giovanni P <> wrote:
>> Here's something that would not impose speed or scalability problems for
>> CouchDB and could create countless possibilities of better organizing and
>> querying data of various kinds -- mainly docs linked to other docs somehow
>> --, as well as making views more useful (for storing valuable data not
>> contained in the document, instead of just indexing it):
>> 1. documents can have a `_parent` field.
>> 2. documents with a `_parent` field will receive its parent document as an
>> argument to the map functions.
>> 3. every time a document is changed, CouchDB looks for documents that are
>> children of the changed document and remaps then (there could be an
>> internal `_children` view for this purpose).
>> 4. when fetching a document or querying a view with `include_docs`, an
>> optional `include_children` will bring up an array of children at the
>> `_children` field of the document (when updating the doc, this field
>> should
>> not be sent back -- clients have to handle this --, and when it is sent,
>> it
>> is ignored).
>> What are the problems of this approach? One, I think, would be making
>> database queries inside handlers. Well, I just realized this could be a
>> huge problem.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message