On Mon, May 25, 2015 at 3:57 PM, Ilya Khlopotov <iil...@ca.ibm.com> wrote:
> Another example when this functionality is desired is before_doc_update. > Imagine you want to stick extra field into user's profile. The only way to > do it currently is modification of couch_users_db:before_doc_update. > If you replace that with `couch_epi:invoke`. You still wouldn't be able to > achieve what you want since you would have to somehow call > couch_users_db:before_doc_update from your service provider. This situation > get's worse if multiple apps want to inject fields into user's profile. I think this is bad example because: 1. Injecting some fields _before_ document update means that user will update not a document that he expected to. I would like to set color field for apple document as green, but suddenly doc becomes related to orange and sets the color by it own refusing my updates. 2. Explicit is better than implicit. We need discourage dark magic of what _users and _replicator doing with their documents (try to update _replicator document while replication is going on and fails from time to time). 3. I think for your case we need to have update chain, not stack of update hooks in order to preserve user input and apply inner modifications on top of it, but not mix with it. Until now, CouchDB follows Read-Your-Writes model quite good (excluding race condition case with compaction) and there is no reason to break it. -- ,,,^..^,,,
