From user-return-9748-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Apr 05 11:55:05 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 69200 invoked from network); 5 Apr 2010 11:55:05 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Apr 2010 11:55:05 -0000 Received: (qmail 70102 invoked by uid 500); 5 Apr 2010 11:55:04 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 70057 invoked by uid 500); 5 Apr 2010 11:55:03 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 70049 invoked by uid 99); 5 Apr 2010 11:55:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Apr 2010 11:55:03 +0000 X-ASF-Spam-Status: No, hits=3.6 required=10.0 tests=FREEMAIL_FROM,FS_REPLICA,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ben2004uk@googlemail.com designates 74.125.82.52 as permitted sender) Received: from [74.125.82.52] (HELO mail-ww0-f52.google.com) (74.125.82.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Apr 2010 11:54:57 +0000 Received: by wwd20 with SMTP id 20so2302263wwd.11 for ; Mon, 05 Apr 2010 04:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mqulcJ9McRPkw8AD3693ZQQgDt1cmj/TkAYyplLUXII=; b=kbkt/uNHEXKgFrcxV9I4PFjc8pCeX90wzkoq5OCK5L1Z95qIZZEW78Zq0Dbw+VR2uZ 9wewAaTSFJoATugwHINoO4RP4AhOLBgNCTVvMTM4jNuooAUjA8S+UeqTePDoopcY1a37 noBtOhDyugtGftqp/ZpyqrqhSHWWGSiY65IGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jdJYO68ZliaFpZsiwDEFh4bkiCJOm5g36o3C2JPj/JoJUC/5nP+BXw6scAlmpH3XEc 9U+pOocrfT9ZoT/5ZFlNFgXmiru5IGceKZ52zwjjyF0xcOIyA+2vO8zA2mJheI8WYPe4 DQBCzeBZZ/uAvt6EGjnu9yU9SH5EZlK3vfoC4= MIME-Version: 1.0 Received: by 10.216.221.24 with HTTP; Mon, 5 Apr 2010 04:54:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Apr 2010 12:54:36 +0100 Received: by 10.216.154.206 with SMTP id h56mr3289451wek.94.1270468476911; Mon, 05 Apr 2010 04:54:36 -0700 (PDT) Message-ID: Subject: Re: Replication Filters: When changing restrictions data becomes out of sync From: Ben Hall To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hi Randall, Thanks for the comment. I looked at the _update test cases but couldn't see anything which would fit. http://svn.apache.org/viewvc/couchdb/trunk/share/www/script/test/update_doc= uments.js?view=3Dmarkup How would I issue a DELETE command from javascript against the FirstDB? Thanks Ben On Mon, Apr 5, 2010 at 1:27 AM, Randall Leeds wro= te: > If you're looking for replication to delete documents that don't fit the > filter from the target, you'll have to do that manually. It is never the > place of replication to remove documents on the target. > > What you can do is set up an update handler on second db that deletes > documents exclusivly meant for seconddb from firstdb so in this way you c= an > make it automatic. This doesn't cover the case where a document that used= to > replicate should be deleted everywhere except maindb. > > On Apr 4, 2010 3:58 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. =A0This 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. > > Is there a better way? > > Thanks > > Ben > http://twitter.com/Ben_Hall >