Uploaded image for project: 'CouchDB'
  1. CouchDB
  2. COUCHDB-3227

Inconsistent/odd behaviour of the new ?stable=X&update=Y API



    • Bug
    • Status: Closed
    • Major
    • Resolution: Won't Fix
    • None
    • None
    • Database Core
    • None


      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.




            Unassigned Unassigned
            robfraz Robert Frazier
            0 Vote for this issue
            2 Start watching this issue