Handle new_edits parameter on PUT (save, update) to avoid creation of conflict document

[hufon]

Please read these guidelines before opening an issue.

Bug Description

On API documents, there's a new_edits parameter on put request https://docs.couchdb.org/en/stable/api/document/common.html#put--db-docid This parameter is important because it avoids creation of conflict documents in the db. By default it's true...

On Java cloudant API there's no way to set this parameter on save

1. Steps to reproduce and the simplest code sample possible to demonstrate the issue

2. What you expected to happen

You should have a parameter to update method to pass new_edits

3. What actually happened

On Java cloudant API there's no way to set this parameter on save

Environment details

[mojito317]

Hi @hufon!

The default "new_edits": true is exactly the setting that prevents the insertion of conflicting documents. If you would not like to create conflicts intentionally, this is the setting you need, and it is not necessary to set it.

If you do want to change it to false that will not prevent document conflicts, but I assume here it is not the plan, then I would recommend taking a glance at our new pre-release library where the new_edits property can be set as well: https://github.com/IBM/cloudant-java-sdk

If you are interested in what kind of conflicts can happen in a database inevitably I would recommend reading this Cloudant blog post:

One of the consequences of eventual consistency is that documents might enter a conflicted state if the same version of a document is modified in different ways on two disconnected nodes. ... Even in a small Cloudant cluster, a conflict can arise if changes to the same document are sent to two nodes at the same time. etc

[hufon]

with default new_edits: true i have conflicts documents when i got a 419 precondition failed.

[mojito317]

Can you please show a code snippet or a curl example where you get a 419? If I understand correctly you would like to use the PUT /{db}/{doc_id} endpoint, do not you?

If you set "new_edits": true, it is natural behavior the server will ignore all modifications that might cause conflicts. It warns you of a problematic update request. In other words: your request is rejected because it would create a conflict. This way you need to fix your document client-side first, then you can upload the resolved document to your database. E.g. get the latest version of the document, merge it with your uploadable one using the current rev then update it.

If you set "new_edits": false, the server will allow creating conflicting documents in the database. This way the responsibility is also yours to resolve the server-side conflicts, but with a special technique. See the How to resolve conflicts section in the Cloudant documentation.

[hufon]

In fact, we have conflict when using saveAttachment method.

[mojito317]

Is your document rev up-to-date when calling saveAttachment?

[hufon]

yes we try , but sometimes, when under load we are in racecondition, where the document has been updated between getting lastest rev and saveAttachment... and the problem that we have, is that saveAttachment create conflicts revisions

[mojito317]

yes we try , but sometimes, when under load we are in racecondition, where the document has been updated between getting lastest rev and saveAttachment...

Now it looks like more an architectural problem than a problem with the client lib itself.

Complete app design is outside the scope of an issue here. If you are an IBM Cloudant or Support for CouchDB customer you can email support@cloudant.com to setup an engagement with our Client Architecture team for more help designing your application. If you are not a customer then I'd recommend the CouchDB slack or users mailing list to have discussions with the wider CouchDB community about best-practices for this type of application.

[ricellis]

Closing this as there is no change needed here.

• As pointed out in linked documentation above there are various race conditions that cannot be avoided with Couch 2.x and 3.x systems.
• AFAICT new_edits isn't applicable to attachment PUT
• We won't add the new_edits option to document PUT here - I'd recommend against it because intentionally overriding the conflict check and creating conflicts in the server revision tree will almost inevitably cause issues, but if you really wanted to do it you can workaround by using executeRequest to make a custom request with the option.