-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return 201 or 202 on Document.save() #49
Comments
Darn it; this should apply to way more than these two. There's also the The real question is, does this 202 code should affect the state of the |
True!
Yes, I think they can only happen when a quorum fails, which means with a cluster. We see them from time to time, which is problematic because sometimes 2 concurrent calls on 2 CouchDB nodes end up on HTTP 202 Accepted, so both clients think their document version is saved for good, whereas there will be a conflict.
I'm not sure this return code affects the |
Hello @bmario, did you had any chance to look into it? |
Can we help you getting this into aiocouch @bmario? |
My problem right now is that I can't judge the impact of the 202 responses on the control flow. I still haven't fully grasped, what the response would look like if the status code is 202. So, I'd love to see a few examples, of what it looks like when directly using the CouchDB API. It would really help to have these. |
CouchDB responses are exactly the same whether it responds with 201 or 202. |
Happy new year @bmario! In your last comment you said it would be helpful for you to play with a CouchDB cluster and see how it behaves. I've setup a small 3 nodes cluster on my local machine so I can help you with the tests. Feel free to ask me to try things. In my setup, to simulate a quorum not met, I'm freezing 2 out of 3 cluster nodes using It would be helpful for us to track these 202 when they happen so we can adapt our code behavior. Thanks! |
Hello @bmario! I too would be interested in accessing more info from the CouchDB HTTP API, especially the status code which is part of the CouchDB API (and why not also headers, or the raw HTTP answer). You can see for example that the official CouchDB nano library gives access to the If you don't have the time to do it yourself I'd be motivated for working on a PR, but before doing so I need to know if you will be willing to look at it once it's opened and willing to integrate it if it's well written. What do you think? |
I'm certainly willing to merge a change like that. However, I don't see how there is a way to keep the current interface. One obvious place would be to return the response headers from |
At the
Right, In my case I only need the HTTP code, but other users could want to read the HTTP headers or other things. In this case, other interfaces could be more future-proof: >>> await Document(db, 'id', {'a': 1}).save()
{'http_code': 201}
>>> await Document(db, 'id', {'a': 1}).save(return_http_code=True)
{'http_code': 201}
>>> await Document(db, 'id', {'a': 1}).save(return_http_response=True)
HTTPResponse(status=201) |
These methods are `Document.save()`, `Document.delete()`, and `Document.copy()`. Breaking change: `Document.copy()` does not return a `Document` anymore. You can use the ETag and fetch the document yourself. Fixes #49
Hello @bmario,
We need to know whether the
PUT /db/doc
route returned a HTTP 201 or a HTTP 202. Knowing this info is part of the API and documented, so it's legitimate for an aiocouch user to be able to get this return code.Would you be favorable to an improvement to
Document.save()
in order to return this info? Potentially using a parameter likereturn_http_code=True
, which will be passed toRemoteDocument
thenRemoteServer._put()
? E.g.Note: this could also apply to the
PUT /db
route, which works similarly.The text was updated successfully, but these errors were encountered: