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 <[email protected]> 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 <[email protected]> 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 >
