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

[cloidjgreen]

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

So on line 111 of nano I changed req.headers = _.extend(req.headers, opts.headers, cfg.defaultHeaders); to 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.

Comments??

[jo]

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

[jo]

Please reopen if needed.

[cloidjgreen]

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,

Regards Cloid

[jo]

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.

[cloidjgreen]

Two use cases actually.

1. 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 templates.
2. 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.

Regards

Cloid

On Mon, Jun 29, 2015 at 9:01 AM, Johannes Jörg Schmidt < [email protected]> wrote:

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.

— Reply to this email directly or view it on GitHub https://github.com/dscape/nano/issues/281#issuecomment-116674161.

[jo]

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.

[carlosduclos]

This issue has been moved to the new repository, please continue the discussion here.