That's right: validate_doc_update cannot modify a document to store. But it could check if previous version is included into history log stored within update document - what is actually your update handled doing. So clients have to use your update handlers or implement the same logic on their side to by pass validation. -- ,,,^..^,,,
On Wed, Oct 1, 2014 at 11:45 PM, Eric Benzacar <[email protected]> wrote: > As you mentioned, the update_notif_handler and changes feed are things that > are triggered after a document is persisted, so it can cause race > conditions. Ideally, I'm looking to trigger a handler just before it is > persisted. > > I looked into the validate_doc_update function, but even if I want to store > the history log within the document (not opposed to it), I can't seem to > modify the contents in the validate_doc_update function (which is > appropriate). So I'm still no further ahead in figuring out a central > place to do this. > > So then I am reduced to ensure that every updateHandler I call creates a > history log, and posts/put of the document do it as well. Which means that > I am putting code in several different places to perform the same task, > which is error prone and leads to fragmentation. > > Unless I am missing something? > > Thanks, > > Eric > > On Wed, Oct 1, 2014 at 3:30 PM, Alexander Shorin <[email protected]> wrote: > >> Suddenly no. At least completely. You can create your >> validate_doc_update function which will verify that every new stored >> contains some specific data (like previous document version to which >> validate_doc_update also has access), but all this leads to storing >> history log inside single document. If you want to track it >> separately: changes feed and update_notification_handler are your >> friends, but there could be happened race conditions (especially if >> compaction get triggered) so there will be always a chance for you to >> miss some revision. >> -- >> ,,,^..^,,, >> >> >> On Wed, Oct 1, 2014 at 11:18 PM, Eric B <[email protected]> wrote: >> > Thanks for the valid points. But either way (whether through patches or >> > storing the full previous revision), is there a mechanism in CouchDB in >> > which I can require all calls to trigger an updateHandler? In a way, I'm >> > looking more for an update interceptor; something to be run just before a >> > document is actually persisted to the DB, but that is always executed. >> > >> > Thanks, >> > >> > Eric >> > >> > >> > On Wed, Oct 1, 2014 at 3:03 PM, Alexander Shorin <[email protected]> >> wrote: >> > >> >> Storing patches is good until you're in sure that no single patch will >> >> get suddenly deleted. Otherwise you could easily find all your history >> >> broken. Oblivious, but it is the thing to remember when picking this >> >> way of history management. Storing full document copies per revision >> >> is more solid solution for such case: you can easily skip or lose one >> >> or several revisions and be fine, but it also consumes much more disk >> >> space. Trade offs are everywhere, pick up the one that suites you. >> >> -- >> >> ,,,^..^,,, >> >> >> >> >> >> On Wed, Oct 1, 2014 at 10:02 PM, Eric B <[email protected]> wrote: >> >> > I'm new to CouchDB and trying to figure out the best way to store a >> >> history >> >> > of changes for a document. >> >> > >> >> > Originally, I was thinking the thing that makes the most sense is to >> use >> >> > the update function of CouchDB but not entirely sure if I can. Is >> there >> >> > someway to use the update function and modify/create a second >> document in >> >> > the process? >> >> > >> >> > For example, if I have a document which contains notes for a client. >> >> > Everytime I modify the notes document (ie: add new lines or delete >> >> lines), >> >> > I want to maintain the changes made to it. If there was a way to use >> >> > CouchDB's rev fields for this, my problem would be solved, but since >> >> > CouchDB deletes non-current revs upon compaction, that is not an >> option. >> >> > >> >> > So instead, I want to create a "history_log" document, where I can >> just >> >> > store the delta between documents (as a patch, for example). >> >> > >> >> > In order to do this, I need to have my existing document, my new >> >> document, >> >> > compare the changes and write them to a history_log document. But I >> >> don't >> >> > see if/where I can do that within and update handler. >> >> > >> >> > Is there something that can help me do this easily within CouchDB? >> Are >> >> > there patch or json compare functions I can have access to from >> within a >> >> > CouchDB handler? >> >> > >> >> > Thanks, >> >> > >> >> > Eric >> >> >>
