The one "catch" is that the majority of a CouchApp is related to querying
(map/reduce) and formatting (_show/_list) and validating (_update). While
the contents of the _design/app document may be the same, the disk storage
for the results of the map/reduce and _show/_list caching is specific (and
s
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
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 wrote:
> Martin,
>
> I'm not sure what your setup is, but if you had an "app" database (the
> authoritative db for the _design
Thanks for the very interesting discussion!
Benjamin's proposal to distinguish between the replication of "app dbs"
on different hosts and replicating the design documents between
"customer dbs" on the same machine and CouchDB instance reduces the
http-traffic and supports scaling over many mac
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
'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 201
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?
La
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 wrote:
> Hey Gregor,
>
> If you setup continuous replication between your various cus
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 wou
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-ten
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 eac
11 matches
Mail list logo
