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

SQL++
1

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?

2

A bit of googling answers my own question. The answer is yes it is expected to lag, as detailed in https://blog.couchbase.com/acid-properties-couchbase-part-1/ where it states indices are updated asynchronously.

3

You can also use SCAN_CONSISTENCY https://docs.couchbase.com/server/5.5/indexes/performance-consistency.html

1 Like
4

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);