couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: More View Changes Input
Date Fri, 03 Oct 2014 20:43:34 GMT
On Fri, Oct 3, 2014 at 4:17 AM, Benoit Chesneau <> wrote:
> On Fri, Oct 3, 2014 at 11:12 AM, <
>> 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

View raw message