Re: Replication Filters: When changing restrictions data becomes out of sync

[J Chris Anderson <jc...@gmail.com>]

On Apr 4, 2010, at 3:57 PM, Ben Hall wrote:

> Hi,
> 
> I have the following setup:
> 
> MainDB
> FirstDB
> SecondDB
> 
> First and Second will contain a subset of the data in MainDB. I
> planned to use Replication Filters to populate the DB.  This is
> working great, until I change a document in MainDB from being
> restricted to FirstDB to being restricted to SecondDB.
> 
> When this happens, replication correctly applies it to SecondDB -
> however it still exists in FirstDB. As such, my data is now
> inconsistent.
> 
> Is this correct? The only thing I can think is that I'm going to have
> to manually delete the document from FirstDB - which is a little bit
> annoying.
> 

Good Question.

Filtered replication is meant to control replication to endpoints that you don't control. In a fully distributed app, there can be no concept of revoking access to something that's already been shared.

In practice (with your dbs behind your firewall), you are best sending a delete to FirstDB, but also avoid replicating the delete from FirstDB to SecondDB.

Perhaps it's possible to split your documents up so that you don't need to revoke them later. Maybe someone on the list can think of a smart way to do revokes inside a firewall. The delete thing seems OK to me -- but you don't want that delete to replicate upstream to MainDB or SecondDB.

Chris

> Is there a better way?
> 
> Thanks
> 
> Ben
> http://twitter.com/Ben_Hall

Re: Replication Filters: When changing restrictions data becomes out of sync

[Randall Leeds <ra...@gmail.com>]

On Tue, Apr 6, 2010 at 03:42, J Chris Anderson <jc...@gmail.com> wrote:
>
> Perhaps it's possible to split your documents up so that you don't need to revoke them later. Maybe someone on the list can think of a smart way to do revokes inside a firewall. The delete thing seems OK to me -- but you don't want that delete to replicate upstream to MainDB or SecondDB.

For this, you can use the _purge functionality, which does not create
a new rev that replicates but removes the document entirely.