Heya,

nice one Adam! :)

As I see it, here are our options:

1. don’t apply this

2. apply this, but disable it by default and let people opt in, either
  - on a per-request basis like _all_docs?multichunkinator=true
  - on a per-instance config basis: [httpd] multichunkinator=true

3. apply this and enable it by default and let people opt out as per 2. with 
false as the option
  - this requires breaking BC and documenting the upgrade path

4. apply this, enable by default and leave no way back
  - BC break needs to be set up as per 3

For either 2. or 3. we get the opportunity of a nice bikeshed over the name of 
the query param / config value.

I think 1. is not a good idea.

2. is a good choice, if we discover that this would cause major inconveniences 
for lots of people in the field (we then could think about swapping this to be 
the default in 3.0.0).

4. seems needlessly aggressive.

Given that this is not a major issue (as per our information now), I’d be 
confident with 3. making 2.0 the BC breaking version number.

Once 2.0.0 betas come out, I’d like to work with all the major CouchDB clients 
to ensure compatibility, we should find out then, the latest, whether we need 
to reverse our stance to, say, 2.


This will require some extra work to allow either behaviour and configuration, 
but I think that’d be worth it.

Did I miss anything?

Best
Jan
-- 





> On 21 Jul 2015, at 17:42, Adam Kocoloski <[email protected]> wrote:
> 
> Hi all,
> 
> CouchDB uses the chunked transfer-encoding capability of HTTP/1.1 to stream 
> _all_docs, _changes, _view and similar responses to clients. We have always 
> sent each row of these responses in a dedicated chunk. Coalescing multiple 
> rows into a single chunk is more efficient and yields throughput improvements 
> of approximately 30%, but this could break clients that have implicitly 
> relied on the row-per-chunk organization.
> 
> So — do any of you knowingly rely on this behavior? How difficult would it be 
> to accommodate this change? Thanks,
> 
> Adam
> 
> P.S. more details on this topic can be found in COUCHDB-2724 and associated 
> Pull Requests:
> 
> https://issues.apache.org/jira/browse/COUCHDB-2724
> https://github.com/apache/couchdb-couch-mrview/pull/22
> https://github.com/apache/couchdb-chttpd/pull/38
> https://github.com/apache/couchdb-mango/pull/9
> 

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/

Reply via email to