incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Bartell <snbart...@gmail.com>
Subject replication by view
Date Wed, 30 Jan 2013 07:53:27 GMT
Benoit,  I'm curious about a comment you made earlier (from Nathans half-baked idea) and have
a few questions to spawn from it:

```
There is another solution though, replication using a view change and real
replication using a view like in rcouch [1]. With the validate_doc_read
function [2]  you can do that. No need for a background process.  Hopefully
this will be merged in couchdb. This have been tested on a relatively large
scale
```

1) If I understand the couch docs correctly, using views as replication filters yields no
performance benefit.  Its just like running plain jane filters.  I figure thats why you are
mentioning rcouch where the replication source is indexed data.  I just want to clarify that
I understand this.

2) For each replicator filter, or view that is run, is a single couchjs process spawned to
handle evaling the javascript?

3) What if we write our views in erlang and then use those as replication filters?  Could
we get around the extra overhead of couchjs processes this way?

4) Can filters be erlang, thus getting around extra couchjs process overhead?

Thanks for any insight on these newb questions.

sb


Mime
View raw message