Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of martinh@gmail.com designates
 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=c0h3p5tpRVcGQH/Kl5cKXYyMb++LvzPCzAgJiFGLIqYR7xK47oZLTheaSNFOobyomX
         7tMbw3Z0rKl08oj6LuTBAUfPky/qijCN2TCPe6BW4WHjdVSMc4h0id7uV+Uga6cJuDMj
         kvUpwlg4jAHQaPsF5G+u/IRB6MoLxDNdWcoMY=
MIME-Version: 1.0
Sender: martinh@gmail.com
In-Reply-To: <AANLkTi=ZAYoiHTQPxznj5i6XXuwD1pQh9y=3iB1-6RX3@mail.gmail.com>
References: <AANLkTinr62TrG4HGia7OX_cs88YZO+tYYhGgakjtYB+w@mail.gmail.com>
	<AANLkTi=5Hu_0B+ekbnc5sxo9t7oXdmwCrD7DQR-e5j-Z@mail.gmail.com>
	<AANLkTin3X4Gwent7Yfx++s=g181fMm6P-mKV1FJQK-b3@mail.gmail.com>
	<4CCE684E.6040600@makkiato.de>
	<12CF5A9C-0FE3-4BED-A51B-05DB34294CC7@apache.org>
	<AANLkTi=qiVNh37aT8ju0XOhkMpPBQSR=to9UCZBNpotT@mail.gmail.com>
	<AANLkTinfLAUDVoaShE1Rttaqek9UGco6s_B52T_uK63F@mail.gmail.com>
	<AANLkTi=zt40XMB8JijPOJORxS9tkQS2Sw0+jG7foYzyT@mail.gmail.com>
	<AANLkTi=tV5sAU8UTyRFg9cybLqVQArmn+D5d-Zq6HjaS@mail.gmail.com>
	<AANLkTi=ZAYoiHTQPxznj5i6XXuwD1pQh9y=3iB1-6RX3@mail.gmail.com>
Date: Tue, 2 Nov 2010 09:20:29 +0000
Message-ID: <AANLkTi=3GvmiNZbPyt_M1=BYGEcKqbbU2LuFb5YHw71Y@mail.gmail.com>
Subject: Re: Sharing design documents between DBs
From: Martin Higham <martin@ocastalabs.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000325572ea69e8b9104940e6f55

--000325572ea69e8b9104940e6f55
Content-Type: text/plain; charset=ISO-8859-1

Thanks, I wasn't aware of the no IP connections required replication. I
wonder whether this works on a BigCouch cluster?

Martin

On 1 November 2010 17:46, Benjamin Young <benjamin@couchone.com> wrote:

> Martin,
>
> I'm not sure what your setup is, but if you had an "app" database (the
> authoritative db for the _design doc you want to share with customers) on
> the same instance of CouchDB with the customer's db's, then your
> replication
> requests would all be local--no IP connections what so ever.
>
> To do that in a multi-instance scenario, you could simply have the app db's
> continuously replicate between the instances, and locally replication to
> the
> customer db's on each particular instance. Or, if you don't want to use
> replication between your instances, you could push your changes into the
> "app" db's on each of the instances. In either case, you'd only be
> generating HTTP traffic on the pushing of the app and/or replication of the
> "app" db's between the machines--so, very low network overhead in either
> case.
>
> Later,
> Benjamin
>
> On Mon, Nov 1, 2010 at 11:10 AM, Martin Higham <martin@ocastalabs.com
> >wrote:
>
> > 'Continuous' replication to thousands of databases means thousands of
> > permanent IP connections. The alternative is that you write a script that
> > fires off replication requests in sequence for all your databases to
> > perform
> > the update. As you say, this shouldn't occur often.
> >
> > Martin
> >
> > On 1 November 2010 14:48, Benjamin Young <benjamin@couchone.com> wrote:
> >
> > > Martin,
> > >
> > > Why not? It's only going to be sending changes. Unless you're
> constantly
> > > updating your app installation or those changes are massive, you
> > shouldn't
> > > run into any trouble.
> > >
> > > Your other option is the "middle-ware" setup, but then you'd loose the
> > > power
> > > of application replication.
> > >
> > > Thoughts?
> > >
> > > Later,
> > > Benjamin
> > >
> > > On Mon, Nov 1, 2010 at 10:30 AM, Martin Higham <martin@ocastalabs.com
> > > >wrote:
> > >
> > > > Until you have one DB per user and then you're looking at replicating
> > the
> > > > design doc to many thousands of databases and continuous replication
> > > > doesn't
> > > > make sense
> > > >
> > > > Martin
> > > >
> > > > On 1 November 2010 14:11, Benjamin Young <benjamin@couchone.com>
> > wrote:
> > > >
> > > > > Hey Gregor,
> > > > >
> > > > > If you setup continuous replication between your various customer
> > db's
> > > > and
> > > > > your primary application database (which would likely only contain
> > the
> > > > main
> > > > > app's design doc), then publication of the app would automatically
> be
> > > > > "rolled out" to the various customer db's. Because these DB's would
> > be
> > > > > "standalone" versions of the app, they could even be on multiple
> > hosts
> > > > > running CouchDB, so you'd remove the single point of failure
> problem
> > > that
> > > > > most web-apps have--as they run (often) through a single server for
> > all
> > > > > customers.
> > > > >
> > > > > Personally, that mode of "multi-tenant" app (via replication) is
> > pretty
> > > > > exciting, and opens up new ways of dealing with load and
> application
> > > > > distribution. Get's the mind reeling, or maybe that's the coffee I
> > just
> > > > > finished... :)
> > > > >
> > > > > Later, Gregor,
> > > > > Benjamin
> > > > >
> > > > > On Mon, Nov 1, 2010 at 6:49 AM, Jan Lehnardt <jan@apache.org>
> wrote:
> > > > >
> > > > > > Hi Gregor,
> > > > > >
> > > > > > On 1 Nov 2010, at 08:12, Gregor Frey wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > when I followed the discussion about the setup of CouchDB in a
> > > hosted
> > > > > > environment, I wondered whether it would be possible to share the
> > > > > > application level software between multiple databases. This would
> > > > enable
> > > > > a
> > > > > > real multi-tenant set-up. Otherwise you must duplicate the
> > > application
> > > > > with
> > > > > > each new tenant.
> > > > > > > Does anybody know whether and how CouchDB supports application
> > > > sharing?
> > > > > >
> > > > > > CouchDB does not support application or document sharing over
> > > > databases.
> > > > > > But nothing stops you from gradually replicating a new design doc
> > > (the
> > > > > > application) to every database.
> > > > > >
> > > > > > Cheers
> > > > > > Jan
> > > > > > --
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--000325572ea69e8b9104940e6f55--