How does N1QL handle the stale parameter?

  1. Does N1QL use “stale=ok” for queries that use created indexes?

  2. Is there an issue with stale documents for buckets that have no indexes created on them? In other words, if a primary index is not created and “SELECT * FROM default” is called, is it possible for the result from the query to be outdated?

Jonathonl,

  • N1QL currently uses the default, which is equivalent to stale=ok

  • If documents are being mutated, it is possible for the results to be “outdated”. The version read and returned by N1QL will satisfy the query conditions.

We are adding secondary indexes that will provide certain snapshot semantics that we define.

So are you saying that when there are no user created indexes (ie, no N1QL views visible in the admin page), there are still secondary incremental map/reduce views that exist behind the scenes?

Essentially what I’m trying to get at is:
When I add a new document to a couchbase bucket that has no views, will subsequent N1QL queries include that document immediately? Or does N1QL use some hidden view(s) in the background, which might be out of date?

If there are no view indexes (or no view indexes matching the query), N1QL currently uses a Couchbase mechanism called ALL_DOCS, which scans the bucket from disk. So the document will be visible to N1QL after it has been persisted.

For DP3 (March), we are considering that N1QL should automatically create a view index on the primary key (i.e. a view index that scans the entire bucket).

Just a little correction. The default stale parameter for views is “update_after”, which return immediately like “ok” and triggers an update afterwards so that subsequent queries might get more up to date results.

we are considering that N1QL should automatically create a view index on the primary key - See more at: http://www.couchbase.com/communities/comment/reply/2342?destination=node/2338#comment-form Ok. I did some testing, and as expected, new documents are not included in immediately subsequent queries when using index #primary but are included immediately when using index #alldocs.

Would there be some query speed advantage to automatically creating a #primary index? The way I see it, adding this to DP3 would add consistency but would make it so that every first query after a set operation would be out of date since it’s using the update_after value for stale. Also, more views means more cpu usage, so why create a #primary view by default when the ALL_DOCS mechanism already exists?

Yes, #primary is more efficient because it is just a list of keys, and no document body. #all_docs returns full document and so is lot more verbose and causes a higher load. In terms of latency, #primary may be slower as it relies on view update (while all_docs is intrinsic to storage). However, when we do support queries at scale, #primary will progressively work better than #alldocs

Yes, #primary is more efficient because it is just a list of keys, and no document body. #all_docs returns full document and so is lot more verbose and causes a higher load. In terms of latency, #primary may be slower as it relies on view update (while all_docs is intrinsic to storage). However, when we do support queries at scale, #primary will progressively work better than #all_docs.

Ok. Thanks for all the quick responses.