incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastian Rothbucher <sebastianrothbuc...@googlemail.com>
Subject Re: Humble feature proposal: a little hierarchy solution with `_parent` field and parents passed to mapfun
Date Thu, 12 Jun 2014 18:57:52 GMT
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 <fiatjaf@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 <ryan.ramage@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 <fiatjaf@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.
>> 
>> 

Mime
View raw message