couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From carlosduclos <>
Subject [GitHub] couchdb-nano issue #9: DB.insert: Can not insert extra headers like If-Match...
Date Fri, 17 Mar 2017 12:51:15 GMT
GitHub user carlosduclos opened an issue:

    DB.insert: Can not insert extra headers like If-Match:rev to handle 'Document update conflict'

    [Original issue](
    This might be just pure ignorance but in attempting to set up CRUD from Angular through
Express/nano to CouchDB I of course ran into the need to handle 'Document update conflict'.
    There seemed to be no path to resolve the problem through DB.insert. The second parameter
accepting only docName at line 372 of nano before assigning the object passed in to qs. I
had set up the insert call with DB.insert(req.body,{docNname:'name',headers{'If-Match':'rev#'}},cb(){});
    Following the pass off of the insertDoc function in nano to the relax function I found
that the code danced all around opts and qs and never included qs.headers into the request
    So on line 111 of nano I changed
    req.headers = _.extend(req.headers, opts.headers, cfg.defaultHeaders);
    req.headers = _.extend(req.headers, opts.headers, qs.headers, cfg.defaultHeaders);
    Now after failing on a DB.insert with a 'Document update conflict' I can get the current
doc rev, add the headers object with and appropriate "If-Match" to the PARAMS, second argument
to insert, and force the update.
    The revision does not necessarily have to be in the If-Match header. Just include the
revision in the doc body, eg
    db.insert({ foo: bar, _rev: '1-asd' }, 'mydoc')
    Yes I can do that too but reviewing the document and resolving differences does not suit
the specific use case I have.
    Thanks for the update.
    Other than this I have found nano to be very elegant. Makes for a very easy marriage between
CouchDB -- Express,
    Sorry, I maybe did not understand your use case. Could you explain it further please?
    However, I really like the change you propose, because its a minimal change which extends
nanos flexibility.
    Two use cases actually.
    I am developing json data templates and as I edit those I am not
    inserting a revision field or maintaining it. I want to be able to load
    these on system boot and apply updates them through an admin utility so do
    not want to have to concern myself with revisions in the case of these
    The application is an collaboration offering system where parties can
    negotiate or bid to collaborate and the offering party will have "GOD"
    rights over the offer. ( offer and bidding all happening on the same
    document. ) So when the offering party decides to accept a collaboration
    the offering party will premtively change the state on the offer document
    regardless of unseen inputs.
    So those are the two things I think I want to do. Not sure it will work
    out this way though. It might turn out to be necessary to deal with these
    race conditions in a different way.
    Still on the learning curve and experimenting continuously.
    Although I recommend to use a different data model approach for 2 (see Document Modeling
to Avoid Conflicts) you can achieve what you want in current nano by just setting doc._rev.
The If-Match header does nothing special than the doc._rev or rev query parameter.
    That said you can also supply the revision as a query string:
    DB.insert(req.body, { docNname: 'name', rev: 'rev#' }, cb)
    Does this help?
    PS: While working with express and nano you might also find connect-nano useful.



If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message