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