couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ramage <>
Subject Re: Humble feature proposal: a little hierarchy solution with `_parent` field and parents passed to mapfun
Date Thu, 12 Jun 2014 17:42:09 GMT
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