On this page本页内容
collMod
¶collMod
makes it possible to add options to a collection or to modify view definitions.
Note
The view modified by this command does not refer to materialized views. For discussion of on-demand materialized views, see $merge
instead.
The command takes the following prototype form:
Starting in MongoDB 4.2
noPadding
and usePowerOf2Sizes
for collMod
.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.For the <collection or view>
, specify the name of a collection or view in the current database.
Use the userFlags
field in the db.collection.stats()
output to check the options enabled for a collection.
index
¶The index
option can change the following properties of an existing index:
Index Property | |
---|---|
expireAfterSeconds |
The number of seconds that determines the expiration threshold of a TTL Collection. If successful, the command returns a document that contains both the old and new values for the changed property:
You can only modify an existing TTL index; i.e. an index with an existing Modifying the index option |
hidden |
A boolen that determines whether the index is hidden or not from the query planner. If the However, if the To hide an index, you must have featureCompatibilityVersion set to Modifying the index option
|
To change index options, specify either the key pattern or name of the existing index and the index option or options you wish to change:
If the index does not exist, the command errors with the message "cannot find index <name|keyPattern> for ns <db.collection>"
.
validator
¶New in version 3.2.版本3.2中的新功能。
validator
allows users to specify validation rules or expressions for a collection. For more information, see Schema Validation.
The validator
option takes a document that specifies the validation rules or expressions. You can specify the expressions using the same operators as the query operators with the exception of : $geoNear
, $near
, $nearSphere
, $text
, and $where
.
Note
admin
, local
, and config
databases.system.*
collections.validationLevel
¶New in version 3.2.版本3.2中的新功能。
The validationLevel
determines how strictly MongoDB applies the validation rules to existing documents during an update.
validationLevel | |
---|---|
"off" |
No validation for inserts or updates. |
"strict" |
Default Apply validation rules to all inserts and all updates. |
"moderate" |
Apply validation rules to inserts and to updates on existing valid documents. Do not apply rules to updates on existing invalid documents. |
validationAction
¶New in version 3.2.版本3.2中的新功能。
The validationAction
option determines whether to error
on invalid documents or just warn
about the violations but allow invalid documents.
Important
Validation of documents only applies to those documents as determined by the validationLevel
.
validationAction | |
---|---|
"error" |
Default Documents must pass validation before the write occurs. Otherwise, the write operation fails. |
"warn" |
Documents do not have to pass validation. If the document fails validation, the write operation logs the validation failure. |
To view the validation specifications for a collection, use the db.getCollectionInfos()
method.
Note
The view modified by this command does not refer to materialized views. For discussion of on-demand materialized views, see $merge
instead.
viewOn
¶The underlying source collection or view for the view. The view definition is determined by applying the specified pipeline
to this source.
Required if modifying a view on a MongoDB deployment that is running with access control.
pipeline
¶The aggregation pipeline that defines the view.
Note
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.
Required if modifying a view on a MongoDB deployment that is running with access control.
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.
Optional. A document expressing the write concern of the drop
command.
Omit to use the default write concern.
If the deployment enforces authentication/authorization, you must have the following privilege to run the collMod
command:
Required Privileges | |
---|---|
Modify a non-capped collection | collMod in the database |
Modify a view |
|
The built-in role dbAdmin
provides the required privileges.
The following example updates the expireAfterSeconds
property of an existing TTL index { lastAccess: 1 }
on a collection named user_log
. The current expireAfterSeconds
property for the index is set to 1800
seconds (or 30 minutes) and the example changes the value to 3600
seconds (or 60 minutes).
If successful, the operation returns a document that includes both the old and new value for the changed property:
Note
To hide an index, you must have featureCompatibilityVersion set to 4.4
or greater. However, once hidden, the index remains hidden even with featureCompatibilityVersion set to 4.2
on MongoDB 4.4 binaries.
The following example hides an existing index on the orders
collection. Specifically, the operation hides the index with the specification { shippedDate: 1 }
from the query planner.
If successful, the operation returns a document that includes both the old and new value for the changed property:
Note
If the operation is successful but the hidden
value has not changed (i.e. hiding an already hidden index or unhiding an already unhidden index), the command omits the hidden_old
and hidden_new
fields from the output.
To hide a text index, you must specify the index by name
and not by keyPattern
.
The following example adds a validator to an existing collection named contacts
.
Note
MongoDB 3.6 adds the $jsonSchema
operator to support JSON Schema validation.
With the moderate
validationLevel
, MongoDB applies validation rules to insert operations and to update operationss to existing documents that already fulfill the validation criteria. Updates to existing documents that do not fulfill the validation criteria are not checked for validity.
With the warn
validationAction
, MongoDB logs any violations but allows the insertion or update to proceed.
For example, the following insert operation violates the validation rule.
However, since the validationAction
is warn
only, MongoDB only logs the validation violation message and allows the operation to proceed:
For more information, see Schema Validation.