A newer version of this documentation is available.

View Latest

Development and production views

To support both the creation and testing of views during development and the deployment of views in production, Couchbase Server supports two different view types: development views and production views. The two view types work identically, but have different purposes and restrictions placed upon their operation.

Due to the nature of the Couchbase cluster and because of the size of the data sets that can be stored across a cluster, the impact of view development needs to be controlled. Creating a view implies the creation of the index, which could slow down the performance of your server while the index is being generated. However, views also need to be built and developed using the actively stored information. Views are created in a development environment to control the impact of views prior to deployment.

Development views

Development views are designed to be used while you are still selecting and designing your view definitions. While a view is in development mode, views operate with the following attributes:

  • By default the development view works on only a subset of the stored information. You can, however, force the generation of a development view information on the full data set.

  • Development views use live data from the selected Couchbase bucket, enabling you to develop and refine your view in real-time on your production data.

  • Development views are not automatically rebuilt, and during a rebalance operation, development views are not updated, even when consistent views are enabled, as this relies on the automated update mechanism. Updating development views in this way would waste system resources.

  • Development views are fully editable and modifiable during their lifetime. You can change and update the view definition for a development view at any time. During development of the view, you can view and edit stored document to help develop the view definition.

  • Development views are accessed from client libraries through a different URL than production views, making it easy to determine the view type and information during development of your application.

Within the Web Console, the execution of a view by default occurs only over a subset of the full set of documents stored in the bucket. You can elect to run the view over the full set using the Web Console.

Because of the selection process, the reduced set of documents may not be fully representative of all the documents in the bucket. You should always check the view execution over the full set.

Production views

Production views are optimized for production use. A production view has the following attributes:

  • Production views always operate on the full data set for their respective bucket.

  • Production views can either be created from the Web Console or through the REST API. From the Web Console, you first create development views and then publish them as production views. Through the REST API, you directly create the production views (and skip the initial development views).

  • Production views cannot be modified through the UI. You can only access the information exposed through a production view. To make changes to a production view, it must be copied to a development view, edited, and re-published.

Views can be updated by the REST API, but updating a production design document immediately invalidates all of the views defined within it. Production views are accessed through a different URL than development views.

View development workflow

The support for the two different view types means that there is a typical work flow for view development, as shown in the figure below:

view types workflow

The above diagram features the following steps:

  1. Create a development view and view the sample view output.

  2. Refine and update your view definition to suit your needs, repeating the process until your view is complete. During this phase you can access your view from your client library and application to ensure it suits your needs.

  3. Once the view definition is complete, apply your view to your entire cluster data set.

  4. Push your development view into production. This moves the view from development into production, and renames the index (so that the index does not need to be rebuilt).

  5. Start using your production view.

Individual views are created as part of a design document. Each design document can have multiple views, and each Couchbase bucket can have multiple design documents. You can therefore have both development and production views within the same bucket while you development different indexes on your data.

For information about working with the view editor and promoting views from development to production, see Views.