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 <[email protected]>: > > 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 <[email protected]> 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 <[email protected]> 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. >> >>
