4. +1 3. Is possible if chunk size in config set to zero. Using query parameter to control that option is not a good idea. So server administrator may decide if his clients needs in such compatibility or not. -- ,,,^..^,,,
On Wed, Jul 22, 2015 at 1:23 PM, Jan Lehnardt <[email protected]> wrote: > 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/ >
