The definition of a view within a design document also creates an index based on the key information defined within each view. The production and use of the index significantly increases the speed of access and searching or selecting documents from the view.
However, the index is not updated when new documents are added or modified in the database. Instead, the index is generated or updated, either when the view is first accessed, or when the view is accessed after a document has been updated. In each case, the index is updated before the view query is executed against the database.
View indexes are updated incrementally in the following situations:
A new document has been added to the database.
A document has been deleted from the database.
A document in the database has been updated.
View indexes are rebuilt entirely when the view definition changes. To achieve this, a 'fingerprint' of the view definition is created when the design document is updated. If the fingerprint changes, then the view indexes are entirely rebuilt. This ensures that changes to the view definitions are reflected in the view indexes.
View index rebuilds occur when one view from the same the view group (i.e. all the views defined within a single a design document) has been determined as needing a rebuild. For example, if if you have a design document with different views, and you update the database, all three view indexes within the design document will be updated.
Because the view is updated when it has been queried, it can result in a delay in returned information when the view is accessed, especially if there are a large number of documents in the database and the view index does not exist. There are a number of ways to mitigate, but not completely eliminate, these issues. These include:
Create the view definition (and associated design documents) on your database before allowing insertion or updates to the documents. If this is allowed while the view is being accessed, the index can be updated incrementally.
Manually force a view request from the database. You can do this either before users are allowed to use the view, or you can access the view manually after documents are added or updated.
Use the /db/_changes method to monitor
for changes to the database and then access the view to
force the corresponding view index to be updated. See
Section 5.4, “GET /db/_changes”
for more information.
Use a monitor with the
update_notification section of the
CouchDB configuration file to monitor for changes to your
database, and trigger a view query to force the view to be
updated. For more information, see
Section 12.5, “Update Notifications”.
None of these can completely eliminate the need for the indexes to be rebuilt or updated when the view is accessed, but they may lessen the effects on end-users of the index update affecting the user experience.
Another alternative is to allow users to access a 'stale' version of the view index, rather than forcing the index to be updated and displaying the updated results. Using a stale view may not return the latest information, but will return the results of the view query using an existing version of the index.
For example, to access the existing stale view
by_recipe in the recipes
design document:
http://couchdb:5984/recipes/_design/recipes/_view/by_recipe?stale=ok
Accessing a stale view:
Does not trigger a rebuild of the view indexes, even if there have been changes since the last access.
Returns the current version of the view index, if a current version exists.
Returns an empty result set if the given view index does exist.
As an alternative, you use the update_after
value to the stale paramater. This causes the
view to be returned as a stale view, but for the update process
to be triggered after the view information has been returned to
the client.
In addition to using stale views, you can also make use of the
update_seq query argument. Using this query
argument generates the view information including the update
sequence of the database from which the view was generated. The
returned value can be compared this to the current update
sequence exposed in the database information (returned by
Section 5.1, “GET /db”).