Robert Frazier created COUCHDB-3227:
---------------------------------------
Summary: Inconsistent/odd behaviour of the new ?stable=X&update=Y
API
Key: COUCHDB-3227
URL: https://issues.apache.org/jira/browse/COUCHDB-3227
Project: CouchDB
Issue Type: Bug
Components: Database Core
Reporter: Robert Frazier
In COUCHDB-3063, the stale view-query mechanism was effectively deprecated in
favour of two parameters that better express the independent concerns of
getting stable results and whether or not to update the view. This replaced
three parameter combinations with a total of six, meaning that there are now
three new ways of querying views that were previously unavailable to us. On
testing, the behaviour of two of the new combinations
{{?stable=true&update=true}} and {{?stable=false&update=lazy}} seems a bit odd.
This is best summarised by the following table (which I hope gets rendered as
I expect it to...):
||#|| New API || Old API || Observed Behaviour (q=8,n=3) ||
|1|{{?stable=true&update=true}}|Didn't exist|Blocks; Only 8 ushard indexers
started
|2|{{?stable=true&update=false}}|{{?stale=ok}}|Non-blocking; no indexers
started; Matches previous API
|3|{{?stable=true&update=lazy}}|{{?stale=update_after}}|Non-blocking; 24
indexers started; Matches previous API
|4|{{?stable=false&update=true}}|stale not defined|Blocks; 24 indexers started;
Matches previous API
|5|{{?stable=false&update=false}}|Didn't exist|Non-blocking; no indexers started
|6|{{?stable=false&update=lazy}}|Didn't exist|Non-blocking; 8 indexers started,
all same node
I'd argue that combinations 1 and 6 in the above should probably start a full
complement of q*n indexers. That said, maybe these behaviours are useful in
some way? They do allow a way of limiting the CPU impact of indexing, for
instance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
