remove negative counts

[Chris Anderson <jc...@apache.org>]

Couch devs,

I've just committed a patch to Futon that removes the use of count=n
where n is less than 0. This is meant as a proof-of-concept that one
can do all necessary pagination without relying on negative counts.
The commit: http://svn.apache.org/viewvc/incubator/couchdb/trunk/share/www/script/browse.js?r1=690590&r2=699023&diff_format=h

Negative counts have two problems:

A) They don't stream to the client - essentially a negative count
request is just like a positive count request with descending=true,
only it is buffered in the server, and reversed before being sent over
HTTP. This means that negative count requests (for large n) require
much more memory than positive count requests.

B) They require an alternate code path, which means more to keep track
of both in terms of code that needs to be written to integrate new
features, as well as test that need to be written (because testing
features with positive count doesn't guarantee that the feature will
work with negative count.)

Maybe there are other reasons to keep negative counts around, but I
can't think of any. I'd like to hear your thoughts before I start work
to remove the negative count stuff from CouchDB's Erlang as well.

Chris

-- 
Chris Anderson
http://jchris.mfdz.com

Re: remove negative counts

[Damien Katz <da...@apache.org>]

I'm fine with removing this functionality as it definitely makes the  
code more convoluted.

The reason I put it in was for easier backwards view paging, which is  
more complicated without it.

-Damien

On Sep 25, 2008, at 2:48 PM, Chris Anderson wrote:

> Couch devs,
>
> I've just committed a patch to Futon that removes the use of count=n
> where n is less than 0. This is meant as a proof-of-concept that one
> can do all necessary pagination without relying on negative counts.
> The commit: http://svn.apache.org/viewvc/incubator/couchdb/trunk/share/www/script/browse.js?r1=690590&r2=699023&diff_format=h
>
> Negative counts have two problems:
>
> A) They don't stream to the client - essentially a negative count
> request is just like a positive count request with descending=true,
> only it is buffered in the server, and reversed before being sent over
> HTTP. This means that negative count requests (for large n) require
> much more memory than positive count requests.
>
> B) They require an alternate code path, which means more to keep track
> of both in terms of code that needs to be written to integrate new
> features, as well as test that need to be written (because testing
> features with positive count doesn't guarantee that the feature will
> work with negative count.)
>
> Maybe there are other reasons to keep negative counts around, but I
> can't think of any. I'd like to hear your thoughts before I start work
> to remove the negative count stuff from CouchDB's Erlang as well.
>
> Chris
>
> -- 
> Chris Anderson
> http://jchris.mfdz.com