Use active_only with replication and deletes doc at application level


#1

Hello,

I am thinking on using active_only flag on _changes with couchbase lite /sync_gateway replication. (this flag, available with SG1.3, discards sending to _changes doc entries with _removed, _deleted).

The rationale behind this is that I want to handle document deletion at application level. Like this, instead of sending for instance 1K deletes to 1K replicated DBs I send one doc to 1K replicated DBs. When this special doc is received, the app makes necessary deletions locally.
The second reason is that I am using apache couchdb to work with Chrome and debug my app. CouchDB does not know how to handle _removed field set by the GW and this is breaking its replication.

Do you foresee some drawback of doing so? Note that, unless I miss it, the only way to get this flag active with _replicate is to ‘hack’ the GW to activate active_only on _changes by default.

Thanks & regards


#2

I think the main concern with moving to a parallel delete processing model would be around concurrency - one of the key benefits of the existing tombstone model is that a delete is just another revision, and gets the benefits of MVCC. Without that, I’d expect issues where users are attempting to update documents that the server already considers deleted (because they haven’t received/processed the delete notification yet).

The second concern would be around whether these deletes are security based (i.e. removals and not deletes). Identifying removals, and whether a given user should delete a document (because they don’t have visibility through any other channels) can be complex, and hard to model with a single ‘delete notification doc’.


#3

Thanks for your valuable feedback Adam.
I need to think about it