Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.214.180 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Sharing design documents between DBs
From: Adam Kocoloski <kocolosk@apache.org>
In-Reply-To: <AANLkTi=3GvmiNZbPyt_M1=BYGEcKqbbU2LuFb5YHw71Y@mail.gmail.com>
Date: Tue, 2 Nov 2010 16:40:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B4FC100-0F65-42E6-B0BE-109E517C4AEE@apache.org>
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>
 <AANLkTi=3GvmiNZbPyt_M1=BYGEcKqbbU2LuFb5YHw71Y@mail.gmail.com>
To: user@couchdb.apache.org

It does not at the moment.  Getting it to work on a BigCouch cluster =
requires significant changes to the replicator.  The replicator is in =
the middle of a major rewrite, so I thought it best to wait till that =
lands before trying to tackle native Erlang replication between two =
BigCouch databases on the same cluster.  Best,

Adam

On Nov 2, 2010, at 5:20 AM, Martin Higham wrote:

> Thanks, I wasn't aware of the no IP connections required replication. =
I
> wonder whether this works on a BigCouch cluster?
>=20
> Martin
>=20
> On 1 November 2010 17:46, Benjamin Young <benjamin@couchone.com> =
wrote:
>=20
>> Martin,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Later,
>> Benjamin
>>=20
>> On Mon, Nov 1, 2010 at 11:10 AM, Martin Higham <martin@ocastalabs.com
>>> wrote:
>>=20
>>> '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.
>>>=20
>>> Martin
>>>=20
>>> On 1 November 2010 14:48, Benjamin Young <benjamin@couchone.com> =
wrote:
>>>=20
>>>> Martin,
>>>>=20
>>>> 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.
>>>>=20
>>>> Your other option is the "middle-ware" setup, but then you'd loose =
the
>>>> power
>>>> of application replication.
>>>>=20
>>>> Thoughts?
>>>>=20
>>>> Later,
>>>> Benjamin
>>>>=20
>>>> On Mon, Nov 1, 2010 at 10:30 AM, Martin Higham =
<martin@ocastalabs.com
>>>>> wrote:
>>>>=20
>>>>> 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
>>>>>=20
>>>>> Martin
>>>>>=20
>>>>> On 1 November 2010 14:11, Benjamin Young <benjamin@couchone.com>
>>> wrote:
>>>>>=20
>>>>>> Hey Gregor,
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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... :)
>>>>>>=20
>>>>>> Later, Gregor,
>>>>>> Benjamin
>>>>>>=20
>>>>>> On Mon, Nov 1, 2010 at 6:49 AM, Jan Lehnardt <jan@apache.org>
>> wrote:
>>>>>>=20
>>>>>>> Hi Gregor,
>>>>>>>=20
>>>>>>> On 1 Nov 2010, at 08:12, Gregor Frey wrote:
>>>>>>>=20
>>>>>>>> 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?
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> Cheers
>>>>>>> Jan
>>>>>>> --
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20