Conflict over saving after real time

[cballevre]

I encountered a problem when working on cozy-settings between real time and saving a document. The document in question is io.cozy.settings.instance but I think that the case can be found in other places.

The document sent by cozy-stack in real time is the CouchDB document. Unlike a call to the JSON Api, the document does not contain the attribute field. The stack also adds calculation fields to the call.

This difference in behaviour means that when a modification is made with a client.save, a 409 error of the conflict type is generated. The document stored in cozy-client does not correspond to the one used by the stack.

Solution 1:
One solution used was to call the JSON Api to retrieve the last object before updating systematically. This is not optimal in terms of performance and network consumption.

Solution 2:
Modify RealTimeQueries to be able to modify the object according to business rules before integrating it into the cozy-client store. I've done an initial PR on cozy-client for this solution, but I've still got to formalise an API that suits everyone.

Solution 3:
The solution would be to unify the document returned by the JSON Api and the real-time feedback so as to have a single source of truth. This is undoubtedly a long-term solution, but @nono, would it be viable for the stack?

If you see any other way of solving the problem, I'd be glad to discuss it.

[nono]

The solution would be to unify the document returned by the JSON Api and the real-time feedback so as to have a single source of truth. This is undoubtedly a long-term solution, but @nono, would it be viable for the stack?

Probably on the long term