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 > >> >
