Yeah, what Paul said is correct. As far as replication, you would be able to manually mediate a view replication with the view changes feed, but there's no built-in functionality to do it for you. Unless you're talking about the view-filtered replication, which will be optimized if the view is sequence indexed.
On Fri, Oct 3, 2014 at 1:43 PM, Paul Davis <[email protected]> wrote: > On Fri, Oct 3, 2014 at 4:17 AM, Benoit Chesneau <[email protected]> > wrote: > > On Fri, Oct 3, 2014 at 11:12 AM, [email protected] < > > [email protected]> wrote: > > > >> Hey all, > >> > >> So, the view changes PRs have been hanging out for a bit (review > welcome!) > >> but things have changed a fair bit since I last emailed wider dev > >> community. Bob's had a chance to do a bit of review (thanks Bob!) and > >> voiced his preference for there to be a single view changes row > returned in > >> the response body for each sequence changed (rather than for each > seq-key > >> pair changed). So, that would mean returning the keys added and removed > >> from the index on each row rather than one key per row. Initially, I > >> thought a format like: > >> > >> {"id": "docid", "add": [{"key": "value"},{"key":"value2"}], "remove": > >> ["key_a", "key_b"], "seq": 5, "changes": [{"_rev": "1-abcdef"}]} > >> > >> (Note: "add" is a list of {"key": "value"} objects rather than a single > >> multi-KV object because duplicate keys can be emitted in a single > change) > >> > >> Though I realized that keys can be non-strings, which would make that > >> return format invalid JSON. So, what I'm currently going with is: > >> > >> {"id": "docid", "add": [["key", "value"],["key", "value2"]], "remove": > >> ["key_a", "key_b"], "seq": 5, "changes": [{"_rev": "1-abcdef"}]} > >> > >> I can see why one might find this esoteric/yucky, so I thought I'd > express > >> the reasoning and ask for some input/alternatives. So, does anyone have > >> thoughts/preferences? > >> > >> In other news, I'll be rebasing/squashing soon to remove some > less-useful > >> commits, but after that I think it'll be mergeable. If anyone feels > >> comfortable to delve into the changes, I'd appreciate some feedback (and > >> hopefully some +1s). > >> > >> Thanks! > >> Ben > >> > > > > Can we have a feature request about that proposal? > > > > I don't think this is a feature so much as asking for input on the > format to be used for view changes. For instance, if we have a > document that emit's three keys, do we have there rows in the output, > or a single row that has a list of the keys that document emitted. > Given that the database update sequence is per document it seems to me > that the view sequence should probably also follow that model or else > we have to decide if we want to create a new update sequence or have > rows with the same sequence number. > > > It is also not clear what it imply, what is the impact on the memory, > > bandwidth? Why this change is needed? > > > > I'd imagine it'd save a bit on bandwidth just by the fact that its not > sending the document id multiple times. I wouldn't expect there to be > a memory difference either way as I'm pretty sure its just formatting > as the bytes go onto the socket more than anything. Granted I haven't > gone back and reviewed the structures so I could be missing details > there as well. > > > Also I am lost in the flux of UI commits and i am not sure now, but is > the > > replication over view changes is enabled? > > > > - benoit >
