Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
None
Description
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.