On Jan 30, 2013, at 12:13 AM, Benoit Chesneau <[email protected]> wrote:
> 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. > This seems like a huge improvement! Replicating with filters always bothered me because a first time replication would need to traverse the entire database. Not to mention the timeout issues which could occur if the db is massive. I just figured it was a necessary evil. > >> 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. Right, but in the case of a javascript filter (not the uber-sweet view changes), is a single couchjs process spawned per filter? > > >> >> 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
