Devs,
I've been thinking there are a few simple options that would magnify
the power of the replicator a lot.
The simplest one is copy-doc by id. You'd post a JSON list of docids
with your replication definition. Those docs would be copied from the
source to the target. This is technically feasible with filtered
replication, but can be much less efficient than using docids if you
only want to replicate a few docs. In particular, I'd like to smooth
the path for replicating design docs around, but replication by id has
a lot of uses.
The fun one is chained map reduce. It occurred to me the other night
that simplest way to present a chainable map reduce abstraction to
users is through the replicator. The action "copy these view rows to a
new db" is a natural fit for the replicator. I imagine this would be
super useful to people doing big messy data munging, and it wouldn't
be too hard for the replicator to handle.
It's as simple as creating a new doc (letting couch pick the uuid) for
each row in the view query (so it works with group_level also). Like:
{
"id" : row_doc_id(),
"key" : row_key(),
"value" : row_value().
"_id" : "2a88e5279811ab202300293d2c24a3e2af03fca0",
"_rev" : "496b8a13f2dc08940825619d954cabaf4e2cb893"
}
Then for secondary queries you'd define a new map reduce on the target db.
If people could use these, let us know so we can work on it.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
