Navigation
This version of the documentation is archived and no longer supported.

Views

A MongoDB view is a queryable object whose contents are defined by an aggregation pipeline on other collections or views. MongoDB does not persist the view contents to disk. A view’s content is computed on-demand when a client queries the view. MongoDB can require clients to have permission to query the view. MongoDB does not support write operations against views.

For example, you can:

  • Create a view on a collection of employee data to exclude any private or personal information (PII). Applications can query the view for employee data that does not contain any PII.
  • Create a view on a collection of collected sensor data to add computed fields and metrics. Applications can use simple find operations to query the data.
  • Create a view that joins two collections containing inventory and order history respectively. Applications can query the joined data without managing or understanding the underlying complex pipeline.

When clients query a view, MongoDB appends the client query to the underlying pipeline and returns the results of that combined pipeline to the client. MongoDB may apply aggregation pipeline optimizations to the combined pipeline.

Note

The following page discusses views. For discussion of on-demand materialized views, see On-Demand Materialized Views instead.

Create View

To create or define a view:

  • Use the db.createCollection() method or the create command:

    db.createCollection(
      "<viewName>",
      {
        "viewOn" : "<source>",
        "pipeline" : [<pipeline>],
        "collation" : { <collation> }
      }
    )
    
  • Use the db.createView() method:

    db.createView(
      "<viewName>",
      "<source>",
      [<pipeline>],
      {
        "collation" : { <collation> }
      }
    )
    

Note

  • You must create views in the same database as the source collection.
  • The view definition pipeline cannot include the $out or the $merge stage. If the view definition includes nested pipeline (e.g. the view definition includes $lookup or $facet stage), this restriction applies to the nested pipelines as well.

Behavior

Views exhibit the following behavior:

Read Only

Views are read-only; write operations on views will error.

The following read operations can support views:

Index Use and Sort Operations

  • Views use the indexes of the underlying collection.

  • As the indexes are on the underlying collection, you cannot create, drop or re-build indexes on the view directly nor get a list of indexes on the view.

  • You cannot specify a $natural sort on a view.

    For example, the following operation is invalid:

    db.view.find().sort({$natural: 1})
    

Projection Restrictions

find() operations on views do not support the following projection operators:

Immutable Name

You cannot rename views.

View Creation

  • Views are computed on demand during read operations, and MongoDB executes read operations on views as part of the underlying aggregation pipeline. As such, views do not support operations such as:
  • If the aggregation pipeline used to create the view suppresses the _id field, documents in the view do not have the _id field.

When you query a view, the:

  • Query filter, projection, sort, skip, limit, and other operations for db.collection.find() are converted to the equivalent aggregation pipeline stages.
  • Converted aggregation pipeline stages are added to the end of the aggregation pipeline for the view. This does not modify the view’s underlying pipeline, which is set when you create the view.
  • Aggregation pipeline optimizer reshapes the view aggregation pipeline stages to improve performance. This does not change the query results.

Sharded View

Views are considered sharded if their underlying collection is sharded. As such, you cannot specify a sharded view for the from field in $lookup and $graphLookup operations.

Views and Collation

  • You can specify a default collation for a view at creation time. If no collation is specified, the view’s default collation is the “simple” binary comparison collator. That is, the view does not inherit the collection’s default collation.
  • String comparisons on the view use the view’s default collation. An operation that attempts to change or override a view’s default collation will fail with an error.
  • If creating a view from another view, you cannot specify a collation that differs from the source view’s collation.
  • If performing an aggregation that involves multiple views, such as with $lookup or $graphLookup, the views must have the same collation.

Public View Definition

Operations that lists collections, such as db.getCollectionInfos() and db.getCollectionNames(), include views in their outputs.

Important

The view definition is public; i.e. db.getCollectionInfos() and explain operations on the view will include the pipeline that defines the view. As such, avoid referring directly to sensitive fields and values in view definitions.

Drop a View

To remove a view, use the db.collection.drop() method on the view.

Modify a View

You can modify a view either by dropping and recreating the view or using the collMod command.