I would use a validate_doc_update function that only permits updates that also accurately record the change under a "history" key (whose value is an array).
Whether the code to make a valid update is client-side or server-side as an update handler is really up to you. B. On 17 Feb 2014, at 07:29, Mark Hahn <[email protected]> wrote: > I keep an update history by using an update handler that adds an entry to > an array in the doc on each update. Why do you say that MVCC conflicts > with this? The history matches the actual surviving record from a > collision. > > > On Sun, Feb 16, 2014 at 11:03 PM, Stanley Iriele <[email protected]>wrote: > >> This may not be too helpful to you but I solved this problem with update >> handlers and a records database..each update returned an update record >> object containing the docid the CTX user old.. All of the old keys and >> new...the new changed keys. >> >> I accumulated them in memory in a server than bulk but them into the >> records db. >> >> This also gave the ability to replay the changes by using a list function >> an folding up that doc ID >> On Feb 16, 2014 10:53 PM, "Jens Alfke" <[email protected]> wrote: >> >>> >>> On Feb 16, 2014, at 9:50 PM, Suraj Kumar <[email protected]> wrote: >>> >>>> While we could use "_changes" API, there is no >>>> way to get the UserCtx. This is the real limitation of changes API due >> to >>>> which we are looking for other ways. >>> >>> It's not a limitation of the changes API, it's a limitation of the >>> database itself. CouchDB simply does not store the information you're >>> asking for, so there's no way for the changes API to discover it. >>> >>>> What would you recommend is the best way to achieve history tracking? >>> >>> Maybe put some kind of proxy in front of CouchDB that can modify the >>> documents on the way in, to add properties storing the time and username? >>> >>> --Jens >>
