Is it expected that searches using indices lag behind document changes?

I am noticing what appear to be race conditions in the running of queries immediately after adding or removing documents, which surprises me so I am wondering if I am doing something wrong.

I have some code that runs the following sequence of pseudo-operations. What surprises me is that if I run the code at full speed the second and third checks fail, while if I step through in a debugger all the checks pass. My experience with SQL databases is that if an insert/delete is complete then queries give results immediately consistent with those queries, hence my surprise.

check size = 0
add a document
check size = 1
remove document
check size = 0

  • “check size” is achieved by running a N1QL query of “SELECT count(*) FROM testbucket where type=‘CrystalStructure’”, where all my documents have a field named type that will match. The query explain plan shows that it is using a covering index I created for the ‘type’ field.
  • all operations contain a lcb_wait() call, which I had expected would synchronise the server and any index updates

Is there some more significant form of “wait” that I need to use to get self consistent results?

A bit of googling answers my own question. The answer is yes it is expected to lag, as detailed in where it states indices are updated asynchronously.

You can also use SCAN_CONSISTENCY

1 Like

Thanks. In case it helps anyone else, setting “requestplus” in the C API is done using the following line

lcb_n1p_setconsistency(params, LCB_N1P_CONSISTENCY_REQUEST);