Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 14A2B9185 for ; Wed, 25 Apr 2012 22:06:41 +0000 (UTC) Received: (qmail 23639 invoked by uid 500); 25 Apr 2012 22:06:39 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 23574 invoked by uid 500); 25 Apr 2012 22:06:39 -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 23565 invoked by uid 99); 25 Apr 2012 22:06:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Apr 2012 22:06:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dave@muse.net.nz designates 209.85.213.180 as permitted sender) Received: from [209.85.213.180] (HELO mail-yx0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Apr 2012 22:06:33 +0000 Received: by yenl4 with SMTP id l4so722811yen.11 for ; Wed, 25 Apr 2012 15:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=muse.net.nz; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=x97q6DlcDTfIPnKAMOQ3uZMRUP175mz5AwbeKF/ISjk=; b=Fpvb3sJhPDgNdy4Xk+lUzLLOtYVSYgeOri4yLRR3xK085BoSKJ5vpgtIjR+lzSZKxs sYLXhtwCQkXRxyHzTShtmnOkYCOGZx6tnC/Y45UxgIilDnHDdZdUlH44SgFPTetkN2WK 1b2t2Y6WWOHL6yGpXUwr0DICNyNeFa5XeY6g4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=x97q6DlcDTfIPnKAMOQ3uZMRUP175mz5AwbeKF/ISjk=; b=BMZRgrJyhTSTYGW0cUI4scnWhxflbWqHBpy4JZYde9DVd06OMviWcik/PdlXsEZesQ O4LGIcr4aBWUTiaZ/2xzUFap+/2n8OgaV295D5xGDeT0SyR50oPh3CIh2u3JBSXAIVzc 66BzvQjPzgX8hnDCxLa2USHSG6UqygNUVJUxqt+yns4xiksJ8SzmePXFPYkxndt5UDqe z9j61sjzNKMdAsk+p+EfwiB9TJiIWVAKkNwAUiLeVbY6nRa/LThPQxW+9/V4dmJTJG/w 740vcjiO4F9sOChkzEOfRnJYHAXse79h1XWEJeBrVPijbibw+Bcq6S80Uwc5GWWgWdbP WM7Q== MIME-Version: 1.0 Received: by 10.236.184.135 with SMTP id s7mr4078084yhm.29.1335391572852; Wed, 25 Apr 2012 15:06:12 -0700 (PDT) Received: by 10.146.147.1 with HTTP; Wed, 25 Apr 2012 15:06:12 -0700 (PDT) X-Originating-IP: [84.112.19.176] In-Reply-To: <4F970183.8080300@netsend.nl> References: <4F970183.8080300@netsend.nl> Date: Thu, 26 Apr 2012 00:06:12 +0200 Message-ID: Subject: Re: replication with document transformation From: Dave Cottlehuber To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQleZCc/oiacK20YBVtjC9MDBbQng/Yya65PWfbQkgXqMn7YMvOvco7JohN4ejWhePQfw/tl X-Virus-Checked: Checked by ClamAV on apache.org On 24 April 2012 21:39, Tim Kuijsten wrote: > I'm currently replicating with filters, this works great to share certain > documents between multiple systems based on their attributes. The thing is, > I'd like to map certain names to a locally used name. > > Example: we have 2 systems that want to share some documents with each > other, based on a certain value for the "company" attribute. > > The owners of database 1 want to share all documents that have "company": > "Webstore Chicago" with the owners of database 2. All fine with a filter, > but the owners of database 2 like to refer to "Webstore Chicago" as > "Webstore 501". Is there a way to somehow transform the document while it's > being replicated by the filter so in 1 database it's represented as > "Webstore Chicago" and in the other db this same doc has "Webstore 501"? > > Maybe if I could replicate the results of a view instead of the direct docs > or something.. > > Regards, > > Tim Hi Tim, sorry I thought I send this through yesterday. I can only think of hacks. Store the core data in a master doc, and have two linked docs that represent the additional (transformed) info for each site. These linked docs are then filterable individually for each site, and you can query include_docs at each end on the core data to retrieve the master + only the site-specific transform. Either munge it back together maybe in a list or show, or do it client side. Sound workable? A+ Dave