Views¶

New in version 3.4.

On this page

Starting in version 3.4, MongoDB adds support for creating read-only views from existing collections or other views.

Create View¶

To create or define a view, MongoDB 3.4 introduces:

the viewOn and pipeline options to the existing create command (and db.createCollection helper):

db.runCommand( { create: <view>, viewOn: <source>, pipeline: <pipeline> } )

or if specifying a default collation for the view:

db.runCommand( { create: <view>, viewOn: <source>, pipeline: <pipeline>, collation: <collation> } )

a new mongo shell helper db.createView():

db.createView(<view>, <source>, <pipeline>, <collation> )

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:
- db.collection.mapReduce(),
- $text operator, since $text operation in aggregation is valid only for the first stage,
- geoNear command and $geoNear pipeline stage.
If the aggregation pipeline used to create the view suppresses the _id field, documents in the view do not have the _id field.

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.

Supported Operations¶

The following operations provide support for views, except for the restrictions mentioned in this page:

Commands	Methods
`create`	`db.createCollection()` `db.createView()`
`collMod`
	`db.getCollection()` `db.getCollectionInfos()` `db.getCollectionNames()`
`find` `distinct` `count`	`db.collection.aggregate()` `db.collection.find()` `db.collection.findOne()` `db.collection.count()` `db.collection.distinct()`

← Databases and Collections Capped Collections →