couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: The replicator needs a superuser mode
Date Thu, 25 Aug 2011 23:14:44 GMT
I see nothing wrong with an admin capability that allows you to break
the rules if it is more convenient for common operations. This is not
really a replicator thing, what we're talking about is giving the
_admin power to invoke skip_validations=true on document updates. This
can be useful for bulk loading known valid data, for instance. Or if
you are an admin and you aren't concerned with validity, just want to
give the user a faithful copy of the wacky invalid database.

So I think we can add that, but it's not really a replicator feature,
let's not get confused.

As far as the _dump and _load we talk about here, it should be
possible to take a _changes feed with include docs and multipart
attachments, and pipe it through gzip, to get the JSON _dump artifact.
I think this is a really good idea.

Another even simpler option that I think is kinda fun, is the ability
to replicate by copying the .couch file to the target. This would only
work if the target didn't exist yet. So you'd copy the (hopefully
compacted) .couch file to the new host, and it would put it into
place, and trigger continuous replication to catch up from there.

For quick launch scenarios (wanna spin up a worker on some box, and
the way to do that is to give it a database over there? you could push
the .couch file, with the worker's views and initial data in it, and
then use traditional replication to merge in the data pertaining to
the woker's particular job.)

So I think there are a lot of legitimate uses for non-Couch API ways
of getting at the data. If there is strong demand from users for one
or another option, we should consider including it.


Chris Anderson

View raw message