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')
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.
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.
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
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:
Original issue
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
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.
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. 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
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:
Does this help?
PS: While working with express and nano you might also find connect-nano useful.