How to manage pouchdb and couchdb synchronization?

Question

The best approach for storing multiple user data is for each user on the database. I use the same approach.

I have couchdb on the server and pouchdb for the mobile application. I maintain the data of each user by creating a separate database for the user in pouchdb and couchdb. This means that I have several databases in couchdb and one database in pouchdb.

usually in a sqlbase database user data is stored in different tables.

so in nosql pouchdb i create a document for each table.

The actual problem I encountered:

I have one document in each database that stores user transactions.

A client transaction is stored in pouchdb when he / she is offline, and when the application receives real-time transaction synchronization with the couchdb user database in the transaction document.

data is stored in the transaction document as follows

{ "_id":"transaction ", "_rev":"1-3e5e140d50bf6a4d873f0c0f3e3deb8c", "data":[ { "transaction_id":"tran_1", "transaction_name":"approve item", "status":"Pending", "ResultMsg":"" }, { "transaction_id":"tran_2", "transaction_name":"approve item", "status":"Pending", "ResultMsg":"" }] } 

All these transactions are performed on the server side, and the result is updated in this document. When any new transaction is executed, I store it in the transaction document in the data attribute.

Now I have 1 transaction in the bag, and couchdb both mean that both are in sync.

Now that the mobile application is offline, it is executing an offline transaction, which is stored in the douch transaction pouchdb.

and on the server side, that 1 transaction is updated to success.

Now, when the application goes on-line and sync, I lose my changes on the server side, and finally, the data in the transactional doc are client pouchdb.

here i'm losing server side data. so this is a good approach or how can I solve it.

Answer 1

What happens is that you have conflicts with the same document, because it is modified with one click by the server and another way by the client. One controversial version wins arbitrarily, and the other loses.

You can resolve conflicts or (a more reasonable solution in your case) store several documents for each user instead of one large document.

Just because you have one database for each user does not mean that you need one document for each user. :) For example, your documents may be:

 {_id: "Tran_1", status: "Pending"} {_id: "Tran_2", status: "Pending"} // etc. 

These documents will be created once on the client and updated once on the server. There is no possibility of conflict. Piece of cake!