On Wed, Jan 30, 2013 at 8:53 AM, Stephen Bartell <[email protected]>wrote:
> 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. > In rcouch the implementation is different this is a real view changes: each time a change is indexed in a view an event is sent. All changes are also indexed in a btree so you can use a since= parameter. It is working like changes on the document database but on an index. Since it's a real view you can also query changes in a range (start_key/end_key ) or for a key. > 2) For each replicator filter, or view that is run, is a single couchjs > process spawned to handle evaling the javascript? > No. It is just getting changes from a the index. There is no couchjs process used except if you also want to filter changes in that view. > > 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? > Again see above; View changes is not about filtering. Though you can filter these changes with an erlang function. > > 4) Can filters be erlang, thus getting around extra couchjs process > overhead? > Yes but it won't be sandboxed. - benoît
