Mongodb Create Table Collection
Creating Collection in MongoDB
The options document contains the following fields :
| Field |
Type |
Description |
| capped |
boolean |
- To create a capped collection, we need to specify true in parallel setting the maximum size in the size field.
|
| autoIndexId |
boolean |
- Specifying false to disable the automatic creation of an index on the _id field.
- Note :
For replica sets, do not set autoIndexId to false.
|
| size |
number |
- Specifying maximum size in bytes for a capped collection.
- Once a capped collection reaches its maximum size, MongoDB removes the older documents to make space for the new documents.
- The field size is required for capped collections and ignored for other collections.
|
| max |
number |
- To Use the max limit, ensure that the size limit, which is required for a capped collection, is sufficient to contain the maximum number of documents.
|
| usePowerOf2Sizes |
boolean |
- Available for the MMAPv1 storage engine only. (MMAPv1 is MongoDB's original storage engine based on memory mapped files)
|
| noPadding |
boolean |
- Available for the MMAPv1 storage engine only.
- With noPadding flag set to be true, the allocation strategy does not include additional space to accommodate document growth, as such, document growth will result in new allocation.
- Use for collections with workloads that are insert-only or in-place updates (such as incrementing counters). Defaults to false.
|
| storageEngine |
document |
- Available for the WiredTiger storage engine only. (WiredTiger storage engine is the default storage engine starting in MongoDB 3.2)
- Allows users to specify configuration to the storage engine on a per-collection basis when creating a collection.
- The value of the storageEngine option should take the following form:
{ <storage-engine-name>: <options> }- Storage engine configuration specified when creating collections are validated and logged to the oplog during replication to support replica sets with members that use different storage engines.
|
| validator |
document |
- Allows users to specify validation rules or expressions for the collection.
- You can specify the expressions using the same operators as the query operators with the exception of $geoNear, $near, $nearSphere, $text, and $where.
- Note :
- Validation occurs during updates and inserts. Existing documents do not undergo validation checks until modification.
- You cannot specify a validator for collections in the admin, local, and config databases.
- You cannot specify a validator for system.* collections.
|
| validationLevel |
string |
- Determines how strictly MongoDB applies the validation rules to existing documents during an update.
| validationLevel |
Description |
| "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 |
string |
- Determines whether to error on invalid documents or just warn about the violations but allow invalid documents to be inserted.
- Note:
Validation of documents only applies to those documents as determined by the validation Level.
| validationAction |
Description |
| "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. |
| "moderate" |
Apply validation rules to inserts and to updates on existing valid documents. Do not apply rules to updates on existing invalid documents. |
|
| indexOptionDefaults |
document |
- Allows users to specify a default configuration for indexes when creating a collection.
- The indexOptionDefaults option accepts a storageEngine document, which should take the following form:
{ <storage-engine-name>: <options> }- Storage engine configuration specified when creating indexes are validated and logged to the oplog during replication to support replica sets with members that use different storage engines.
|
