Loss of functionality (Options) when using the PaginatedViewIterator

[doriancransac]

Hi,

Maybe the answer to my question is obvious, but I'd like to make sure I'm understanding your solution to slow paging with the PaginatedViewIterator correctly (http://guide.couchdb.org/draft/recipes.html#fast). Unless I'm mistaken, you're using the startKey and endKey options as a hack to iterate efficiently through the pages (quicker "skip").

By doing that and by taking a String for the view query as an input of your Iterator, however, you're depriving the user of the effective use of the start and end keys (you're hiding the Options and its access, via the View class). That means that we can now iterate through the paginated data of the view, but we can only do that through the entire view only, forcing us to re-select the data as we read the results.

To me that's a pretty big penalty to swallow in terms of functionality and performance on the client side. But maybe I misunderstood something?

[doriancransac]

I thought about this again, and unless I'm mistaken, I don't think it would be too difficult to keep supporting the sub-range functionality (initial purpose of startKey and endKey). Those boundaries would just have to be taken in account when calculating the initial key and an additional test added when calculating the next key. Is this correct?