Sync Gateway + Peer 2 Peer, different behavior for the same document

Good morning everybody. I have this use case, and I need help about how to deal some kind of documents.

We have a mobile application running on a single device (alias Master) connected to the sync gateway, and we have other N devices (Slaves) connected to the master using the peer 2 peer feature.

We have this kind of documents where they are all spread to all the devices and into the server. Once the user does an operation, modifying these documents, they have to be moved out of the phone channel and stored only to the server through the sync gateway, then once confirmed the “moving” they have to be purged from all the mobile devices.

So this is what I can do at the moment.
On the master, when the documents are in this condition, using the DocumentReplicationListener on the sync gateway replicator, I can verify when the reach the sync gateway so I can PURGE the documents
Same approach on the slaves using the DocumentReplicationListener on the peer 2 peer replicator.

In this case the document has been purged from the master but a slave initially not connected once back online it does not receive the change related to the document and it still exist on the database.

I have tried to DELETE the documents on the master instead to purge them, but in this case the documents have been deleted also on the server.

So basically I think I need to delete the document to send the deletion to the other mobile devices, but this deletion does not have to be propagated to the server.

Thanks for any suggestion and have a nice day.
-Paolo

Yes- purged documents won’t sync.

How are you planning on controlling that? I. Are you planning on tracking all Ids of all documents that were previously pushed and purged on master node and filtering those out when pushing? Yeah- that could work.

But if your goal is to purge the documents on the local CBL clients, then that can’t happen on master node as it needs to still “serve” disconnected clients when they come online.

So if you have some notion of the partition window of the clients then you can set the “expiration date” on document so it will be purged on expiry automatically.

For example,

  • CBL master A sends document D to SGW with state=“foo”
  • Once pushed, set expiration period on Document D to be say 10 min (assume 10 min is the max disconnected time of peers)
  • CBL peer B comes online (within 10 min). Gets document D with state=“foo”. Locally purges.
  • CBL master A auto purge document D when 10 min expires

There are other considerations but this is just to give you a general direction…

Hi Priya,
thanks for your reply.

I was exactly tracking the IDs but it was too painful, first because I was keeping the list in memory, so when I restart the application the deletes go to the server, and if I also save them somewhere I would like to be able to re-generate another document with the same ID if I need it. So I abandoned this approach.

I like your suggestion, and the point is all about how much is the disconnecting time. I was thinking to delete all the database from a slave if it has been disconnected for more than N minutes.

I feel I almost have the full control of the documents and thanks to you and you team.

And again, great job with the talks on couchbase lite. I really liked them.

1 Like