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
