On Monday, November 17, 2014 4:00:31 PM UTC-8, James Norman wrote:
>
> I'm starting to implement a strategy for this.  Let me know if you think 
> this may work or if I'm missing something obvious.  Has anyone else ran 
> into this issue?  It seems it would be immediate once a user logs into a 
> new device.
>
> The issue again is that all of the documents and revisions over the 
> lifetime of a channel are sent to the client, even if they have a deleted 
> revision.  If a user creates and deletes data and purges it locally over 
> time, then logs into a new device, all of this data is re-sent to the new 
> device.  If they were to use this as a chat application over a year, then 
> log into a new device all the data will be sent again, which could 
> potentially be GB of data.
>
> Ideally I think the sync-gateway should not send a document if it has a 
> deleted revision and the document was created and deleted in the time frame 
> since the last sync.  Another option would be to have a way to delete or 
> archive a document in the sync gateway that would purge it from the clients 
> and not re-sync it to new clients.
>
>
I like this idea of a special kind of purge tombstone, something like a 
delete, that sync gateway uses to tell databases to purge a document 
locally. I think this would be different than deletes, which you might want 
to have around for a while especially in case of p2p where you want clients 
to be able to tell each other to delete stuff, not just listen to the 
server for deletes.

But if the server has a worker that takes any document that's been deleted 
for more than 2 weeks and (insert application criteria) and turns it into 
one of these purge tombstones, then clients can avoid fetching content via 
revs diff, the purge could even be communicated in the changes feed.

Chris
 

> My workaround is to have a service on the server that decides the logic to 
> delete documents.  If they are old and can be archived, have a deleted 
> revision etc.  This will delete or archive the document directly to the 
> couchbase server so that the sync gateway will not sync the document ever. 
>  It will also need to tell the clients to purge this recently deleted 
> document.  This will be done either by rest call or by using existing CB 
> architecture by creating a document with the purged ID as a property.
>
> As it is there's really no way to sync deletions and the data can grow 
> without bounds.  I understand the reason and that deletions are just 
> revisions, but there has to a way to limit the amount of data that is sent 
> to a new device, and a way to sync deletions to other clients so the 
> database doesn't grow without bounds.
>
> Thanks for any advice -james
>

-- 
You received this message because you are subscribed to the Google Groups 
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mobile-couchbase/59b5ed3e-c94b-4c4f-bc29-ff0adbc7a487%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to