Is there any technical reason why _revisions cannot be returned with _changes and/or views?

[Robert Payne <ro...@me.com>]

One of the major sync bottle necks we have (even with _bulk_get support) is that the changes feed as well as views cannot have the revs=true parameter in addition to include_docs=true to ensure all returned documents include their revisions list. We need these revision lists to ensure our app can do offline edits and then upload them with the _bulk_docs + new_edits flag.

Digging through the source it looks pretty easy to add support to allow revs=true to be included, but I'm curious if there is any reason why this would be a bad idea?

Cheers,
Robert

Re: Is there any technical reason why _revisions cannot be returned with _changes and/or views?

[Robert Payne <ro...@me.com>]

Hey Adam,

Perfect, I'm hoping I can submit this as a PR so one could add ?revs=true on:

/_changes
/_design/*/_view/*
/_find

It's actually incredibly easy to add to the first two just a few tweaks to how the HTTP params are parsed and used, Mango is a bit trickier since it proxies to the mrview API's but I'll see what I can do.

Hopefully I can submit this as a PR after I'm finished.

Cheers,
Robert

> On 13/12/2016, at 4:23 PM, Adam Kocoloski <ko...@apache.org> wrote:
> 
> Hi Robert, that seems like a fine idea.
> 
> I think the lack of _revisions support in the changes feed is largely a historical artifact. Once upon a time the seq_tree that powers the changes feed only had access to the leaf revisions of each document as opposed to the full revision tree. If you wanted the full revision tree you needed to do a separate btree lookup on the id_tree, and so the changes feed avoided that overhead. In 2.0 we include direct access to the revision tree in both btrees, and so the overhead of adding _revisions to the feed directly should be much smaller.
> 
> Cheers, Adam
> 
>> On Dec 12, 2016, at 9:27 PM, Robert Payne <ro...@me.com> wrote:
>> 
>> One of the major sync bottle necks we have (even with _bulk_get support) is that the changes feed as well as views cannot have the revs=true parameter in addition to include_docs=true to ensure all returned documents include their revisions list. We need these revision lists to ensure our app can do offline edits and then upload them with the _bulk_docs + new_edits flag.
>> 
>> Digging through the source it looks pretty easy to add support to allow revs=true to be included, but I'm curious if there is any reason why this would be a bad idea?
>> 
>> Cheers,
>> Robert
> 

Re: Is there any technical reason why _revisions cannot be returned with _changes and/or views?

[Adam Kocoloski <ko...@apache.org>]

Hi Robert, that seems like a fine idea.

I think the lack of _revisions support in the changes feed is largely a historical artifact. Once upon a time the seq_tree that powers the changes feed only had access to the leaf revisions of each document as opposed to the full revision tree. If you wanted the full revision tree you needed to do a separate btree lookup on the id_tree, and so the changes feed avoided that overhead. In 2.0 we include direct access to the revision tree in both btrees, and so the overhead of adding _revisions to the feed directly should be much smaller.

Cheers, Adam

> On Dec 12, 2016, at 9:27 PM, Robert Payne <ro...@me.com> wrote:
> 
> One of the major sync bottle necks we have (even with _bulk_get support) is that the changes feed as well as views cannot have the revs=true parameter in addition to include_docs=true to ensure all returned documents include their revisions list. We need these revision lists to ensure our app can do offline edits and then upload them with the _bulk_docs + new_edits flag.
> 
> Digging through the source it looks pretty easy to add support to allow revs=true to be included, but I'm curious if there is any reason why this would be a bad idea?
> 
> Cheers,
> Robert