This specification outlines the details on how Read Your Own Write (RYOW). The provided code will be using reflect how an implementation in Python might look like.
Throughout the spec there's a common architecture of the system, that consists of three parts:
In a typical web application the client will be the browser. It interacts through HTTP with the Application.
The application is the business logic that runs server-sided and call out to Couchbase. Couchbase itself consists of two parts, the Storage and the Indexer.
Couchbase is the server. The details on what happens within Couchbase can be found in the RYOW specification
There are several options on how to handle the RYOW when you interact with Couchbase. Couchbase will return an opaque token on any mutations like inserts or updates. This token can either be handled by the SDKs Couchbase provides, by the application or by the client.
The application receives the token on a mutation and stores it in a variable. On the next view reuqest it's included.
# `cb` is the connection object
result = cb.set('key', 'value')
token = result.mutation_id
view_result = cb.query('ddocname', 'viewname', block_until=[token])
It gets harder when you want to make sure multiple mutations are included in the next view request, you would need to keep track of all tokens
# `cb` is the connection object
result1 = cb.set('key1', 'value')
result2 = cb.set('key2', 'value')
tokens = [result1.mutation_id, result2.mutation_id]
view_result = cb.query('ddocname', 'viewname', block_until=tokens)
You can easily imagine that the mutation_id as shown in the "Passing to application" section could easily be passed on to the client. The client would then include that token when it requests something from the application that would lead to a view query.
The SDKs can provide an API so that the RYOW is opaque to the application and it won't need to care about the details. It will be guaranteed that the most recent mutation is included in the subsequent view request.
# `cb` is the connection object
cb.block_view = True
cb.set('key1', 'value')
cb.set('key2', 'value')
# Internally in the SDK the `mutation_id` of all requests
# will be stored and supplied with the query
# The view request can clear out the supplied mutations as any subsequent
# request is also guaranteed to have seen the mutations.
view_result = cb.query('ddocname', 'viewname')
To make all that work, not only the view engine needs to change, but also the memcached protocol. An additional field that contains that token will be needed.