On Jan 24, 2010, at 3:09 AM, Chris Anderson wrote:
> 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
This one would be very useful in my domain. We have groups of expert
collaborators editing terminologies as part of a curation process. There is a
workflow process that tracks assignments, conflict reports, etc.. It has a
notion of change sets. Being able to replicate a specific set of ids would fit
like a glove.
> 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.
This would be awesome. So it'd be a two step process, replicating a view to a
new db, over which new map/reduces pairs can be run?
>
> 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
