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?
It is also not clear what it imply, what is the impact on the memory,
bandwidth? Why this change is needed?
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
