Humble feature proposal: a little hierarchy solution with `_parent` field and parents passed to mapfun

[Giovanni P <fi...@gmail.com>]

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.

Re: Humble feature proposal: a little hierarchy solution with `_parent` field and parents passed to mapfun

[Sebastian Rothbucher <se...@googlemail.com>]

Hi Giovanni,

You can always break the system somehow, 'now' is another good way - but why ;-)

Anyway: view collation might already provide some of the things you want - in a rock-solid way. 
http://docs.couchdb.org/en/latest/couchapp/views/collation.html

Good luck!
     Sebastian


Von meinem iPhone gesendet

> Am 12.06.2014 um 20:36 schrieb Giovanni P <fi...@gmail.com>:
> 
> 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 <ry...@gmail.com> 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 <fi...@gmail.com> 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.
>> 
>> 

Re: Humble feature proposal: a little hierarchy solution with `_parent` field and parents passed to mapfun

[Giovanni P <fi...@gmail.com>]

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 <ry...@gmail.com> 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 <fi...@gmail.com> 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.
>>
>
>

Re: Humble feature proposal: a little hierarchy solution with `_parent` field and parents passed to mapfun

[Ryan Ramage <ry...@gmail.com>]

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 <fi...@gmail.com> 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.
>