Mongoose: Schemas

mongoose
Schemas
If you haven't yet done so, please take a minute to read the quickstart to get an idea of how
Mongoose works. If you are migrating from 5.x to 6.x please take a moment to read the migration
guide.
De ning your schema

Creating a model
Ids
Instance methods
Statics
Query Helpers
Indexes
Virtuals
Aliases
Options
With ES6 Classes
Pluggable
Further Reading
De ning your schema
Everything in Mongoose starts with a Schema. Each schema maps to a MongoDB collection and
de nes the shape of the documents within that collection.
import mongoose from 'mongoose';

const { Schema } = mongoose;
const blogSchema = new Schema({

title: String, // String is shorthand for {type: String}
author: String,
body: String,
comments: [{ body: String, date: Date }],
date: { type: Date, default: Date.now },
hidden: Boolean,
meta: {
votes: Number,
favs: Number
}
});
If you want to add additional keys later, use the Schema#add method.
Each key in our code blogSchema de nes a property in our documents which will be cast to its
associated SchemaType. For example, we've de ned a property title which will be cast to the
String SchemaType and property date which will be cast to a Date SchemaType.
Notice above that if a property only requires a type, it can be speci ed using a shorthand
notation (contrast the title property above with the date property).
Keys may also be assigned nested objects containing further key/type de nitions like the meta
property above. This will happen whenever a key's value is a POJO that doesn't have a type
property.
In these cases, Mongoose only creates actual schema paths for leaves in the tree. (like
meta.votes and meta.favs above), and the branches do not have actual paths. A side-e ect of
this is that meta above cannot have its own validation. If validation is needed up the tree, a path
needs to be created up the tree - see the Subdocuments section for more information on how to
do this. Also read the Mixed subsection of the SchemaTypes guide for some gotchas.
The permitted SchemaTypes are:
String
Number
Date
Bu er
Boolean
Mixed
ObjectId
Array
Decimal128
Map
Read more about SchemaTypes here.
Schemas not only de ne the structure of your document and casting of properties, they also
de ne document instance methods, static Model methods, compound indexes, and document
lifecycle hooks called middleware.
Creating a model
To use our schema de nition, we need to convert our blogSchema into a Model we can work
with. To do so, we pass it into mongoose.model(modelName, schema) :
const Blog = mongoose.model('Blog', blogSchema);

// ready to go!
Ids
By default, Mongoose adds an _id property to your schemas.
const schema = new Schema();
schema.path('_id'); // ObjectId { ... }
When you create a new document with the automatically added _id property, Mongoose
creates a new _id of type ObjectId to your document.
const Model = mongoose.model('Test', schema);
const doc = new Model();

doc._id instanceof mongoose.Types.ObjectId; // true
You can also overwrite Mongoose's default _id with your own _id . Just be careful: Mongoose
will refuse to save a document that doesn't have an _id , so you're responsible for setting _id if
you de ne your own _id path.
const schema = new Schema({ _id: Number });


await doc.save(); // Throws "document must have an _id before saving"
doc._id = 1;
await doc.save(); // works
Instance methods
Instances of Models are documents. Documents have many of their own built-in instance
methods. We may also de ne our own custom document instance methods.
// define a schema
const animalSchema = new Schema({ name: String, type: String },
{
// Assign a function to the "methods" object of our animalSchema through schema options.
// By following this approach, there is no need to create a separate TS type to define the
methods: {
findSimilarTypes(cb) {
return mongoose.model('Animal').find({ type: this.type }, cb);
}
}
});
// Or, assign a function to the "methods" object of our animalSchema

animalSchema.methods.findSimilarTypes = function(cb) {
return mongoose.model('Animal').find({ type: this.type }, cb);
};
document by which this method is called
Now all of our animal instances have a findSimilarTypes method available to them.
const Animal = mongoose.model('Animal', animalSchema);

const dog = new Animal({ type: 'dog' });
dog.findSimilarTypes((err, dogs) => {

console.log(dogs); // woof
});
Overwriting a default mongoose document method may lead to unpredictable results. See
this for more details.
The example above uses the Schema.methods object directly to save an instance method.
You can also use the Schema.method() helper as described here.
Do not declare methods using ES6 arrow functions ( => ). Arrow functions explicitly prevent
binding this , so your method will not have access to the document and the above
examples will not work.
Statics
You can also add static functions to your model. There are three equivalent ways to add a static:
Add a function property to the second argument of the schema-constructor ( statics )

Add a function property to schema.statics
Call the Schema#static() function
// define a schema
{
// Assign a function to the "statics" object of our animalSchema through schema options.
statics: {
findByName(name) {
return this.find({ name: new RegExp(name, 'i') });
}
}
}); check all these three syntaxes
// Or, Assign a function to the "statics" object of our animalSchema

animalSchema.statics.findByName = function(name) {
return this.find({ name: new RegExp(name, 'i') });
};
// Or, equivalently, you can call ànimalSchema.static()`.
animalSchema.static('findByBreed', function(breed) { return this.find({ breed }); });

let animals = await Animal.findByName('fido');
animals = animals.concat(await Animal.findByBreed('Poodle'));
Do not declare statics using ES6 arrow functions ( => ). Arrow functions explicitly prevent binding
this , so the above examples will not work because of the value of this .
Query Helpers
You can also add query helper functions, which are like instance methods but for mongoose
queries. Query helper methods let you extend mongoose's chainable query builder API.
// define a schema
{
// Assign a function to the "query" object of our animalSchema through schema options.
query:{
byName(name){
return this.where({ name: new RegExp(name, 'i') })
}
}
});
// Or, Assign a function to the "query" object of our animalSchema

animalSchema.query.byName = function(name) {
return this.where({ name: new RegExp(name, 'i') })
};
Animal.find().byName('fido').exec((err, animals) => {

console.log(animals);
});
Animal.findOne().byName('fido').exec((err, animal) => {

console.log(animal);
});
Indexes
MongoDB supports secondary indexes. With mongoose, we de ne these indexes within our
Schema at the path level or the schema level. De ning indexes at the schema level is necessary
when creating compound indexes.
const animalSchema = new Schema({

name: String,
type: String,
tags: { type: [String], index: true } // path level
});
animalSchema.index({ name: 1, type: -1 }); // schema level
See SchemaType#index() for other index options.
When your application starts up, Mongoose automatically calls createIndex for each de ned
index in your schema. Mongoose will call createIndex for each index sequentially, and emit an
'index' event on the model when all the createIndex calls succeeded or when there was an
error. While nice for development, it is recommended this behavior be disabled in production
since index creation can cause a signi cant performance impact. Disable the behavior by setting
the autoIndex option of your schema to false , or globally on the connection by setting the
option autoIndex to false .
mongoose.connect('mongodb://user:[email protected]:port/database', { autoIndex: false });

// or
mongoose.createConnection('mongodb://user:[email protected]:port/database', { autoIndex: false
// or
mongoose.set('autoIndex', false);
// or
animalSchema.set('autoIndex', false);
// or
new Schema({..}, { autoIndex: false });
Mongoose will emit an index event on the model when indexes are done building or an error
occurred.
// Will cause an error because mongodb has an _id index by default that
// is not sparse
animalSchema.index({ _id: 1 }, { sparse: true });
Animal.on('index', error => {

// "_id index cannot be sparse"
console.log(error.message);
});
See also the Model#ensureIndexes method.
Virtuals
Virtuals are document properties that you can get and set but that do not get persisted to
MongoDB. The getters are useful for formatting or combining elds, while setters are useful for
de-composing a single value into multiple values for storage.
// define a schema
const personSchema = new Schema({
name: {
first: String,
last: String
}
});
// compile our model

const Person = mongoose.model('Person', personSchema);
// create a document
const axl = new Person({
name: { first: 'Axl', last: 'Rose' }
});
Suppose you want to print out the person's full name. You could do it yourself:
console.log(axl.name.first + ' ' + axl.name.last); // Axl Rose
But concatenating the rst and last name every time can get cumbersome. And what if you want
to do some extra processing on the name, like removing diacritics? A virtual property getter lets
you de ne a fullName property that won't get persisted to MongoDB.
// That can be done either by adding it to schema options:

name: {
first: String,
last: String
}
}, {
virtuals: {
fullName: {
get() {
return this.name.first + ' ' + this.name.last;
}
}
}
});
// Or by using the virtual method as following:

personSchema.virtual('fullName').get(function() {
});
Now, mongoose will call your getter function every time you access the fullName property:
console.log(axl.fullName); // Axl Rose
If you use toJSON() or toObject() mongoose will not include virtuals by default. This includes
the output of calling JSON.stringify() on a Mongoose document, because JSON.stringify()
calls toJSON() . Pass { virtuals: true } to either toObject() or toJSON() .
You can also add a custom setter to your virtual that will let you set both rst name and last
name via the fullName virtual.
// Again that can be done either by adding it to schema options:

name: {
first: String,
last: String
}
}, {
virtuals: {
fullName: {
get() {
}
set(v) {
this.name.first = v.substr(0, v.indexOf(' '));
this.name.last = v.substr(v.indexOf(' ') + 1);
}
}
}
});
// Or by using the virtual method as following:

personSchema.virtual('fullName').
get(function() {
}).
set(function(v) {
this.name.first = v.substr(0, v.indexOf(' '));
this.name.last = v.substr(v.indexOf(' ') + 1);
});
axl.fullName = 'William Rose'; // Now àxl.name.first` is "William"
Virtual property setters are applied before other validation. So the example above would still
work even if the first and last name elds were required.
Only non-virtual properties work as part of queries and for eld selection. Since virtuals are not
stored in MongoDB, you can't query with them.
You can learn more about virtuals here.
Aliases
Aliases are a particular type of virtual where the getter and setter seamlessly get and set another
property. This is handy for saving network bandwidth, so you can convert a short property name
stored in the database into a longer name for code readability.

n: {
type: String,
// Now accessing `name` will get you the value of `n`, and setting `name` will set the v
alias: 'name'
}
});
// Setting `name` will propagate to `n`

const person = new Person({ name: 'Val' });
console.log(person); // { n: 'Val' }
console.log(person.toObject({ virtuals: true })); // { n: 'Val', name: 'Val' }
console.log(person.name); // "Val"
person.name = 'Not Val';

console.log(person); // { n: 'Not Val' }
You can also declare aliases on nested paths. It is easier to use nested schemas and
subdocuments, but you can also declare nested path aliases inline as long as you use the full
nested path nested.myProp as the alias.
const childSchema = new Schema({

n: {
type: String,
alias: 'name'
}
}, { _id: false });
const parentSchema = new Schema({

// If in a child schema, alias doesn't need to include the full nested path
c: childSchema,
name: {
f: {
type: String,
// Alias needs to include the full nested path if declared inline
alias: 'name.first'
}
}
});
Options
Schemas have a few con gurable options which can be passed to the constructor or to the set
method:
new Schema({..}, options);
// or
const schema = new Schema({..});

schema.set(option, value);
Valid options:
autoIndex
autoCreate
bu erCommands
bu erTimeoutMS
capped
collection
discriminatorKey
id
_id
minimize
read
writeConcern
shardKey
statics
strict
strictQuery
toJSON
toObject
typeKey
validateBeforeSave
versionKey
optimisticConcurrency
collation
timeseries
selectPopulatedPaths
skipVersioning
timestamps
storeSubdocValidationError
methods
query
option: autoIndex
By default, Mongoose's init() function creates all the indexes de ned in your model's schema
by calling Model.createIndexes() after you successfully connect to MongoDB. Creating indexes
automatically is great for development and test environments. But index builds can also create
signi cant load on your production database. If you want to manage indexes carefully in
production, you can set autoIndex to false.
const schema = new Schema({..}, { autoIndex: false });

const Clock = mongoose.model('Clock', schema);
Clock.ensureIndexes(callback);
The autoIndex option is set to true by default. You can change this default by setting
mongoose.set('autoIndex', false);
option: autoCreate
Before Mongoose builds indexes, it calls Model.createCollection() to create the underlying

collection in MongoDB by default. Calling createCollection() sets the collection's default
collation based on the collation option and establishes the collection as a capped collection if you
set the capped schema option.
You can disable this behavior by setting autoCreate to false using

mongoose.set('autoCreate', false) . Like autoIndex , autoCreate is helpful for development
and test environments, but you may want to disable it for production to avoid unnecessary
database calls.
Unfortunately, createCollection() cannot change an existing collection. For example, if you

add capped: { size: 1024 } to your schema and the existing collection is not capped,
createCollection() will not overwrite the existing collection. That is because the MongoDB
server does not allow changing a collection's options without dropping the collection rst.
const schema = new Schema({ name: String }, {

autoCreate: false,
capped: { size: 1024 }
});
model name is the collection name and all the object
const Test = mongoose.model('Test', schema); of this model are documents of this collection
// No-op if collection already exists, even if the collection is not capped.

// This means that `capped` won't be applied if the 'tests' collection already exists.
await Test.createCollection();
option: bu erCommands
By default, mongoose bu ers commands when the connection goes down until the driver
manages to reconnect. To disable bu ering, set bufferCommands to false.
const schema = new Schema({..}, { bufferCommands: false });
The schema bufferCommands option overrides the global bufferCommands option.
mongoose.set('bufferCommands', true);
// Schema option below overrides the above, if the schema option is set.
const schema = new Schema({..}, { bufferCommands: false });
option: bu erTimeoutMS
If bufferCommands is on, this option sets the maximum amount of time Mongoose bu ering will
wait before throwing an error. If not speci ed, Mongoose will use 10000 (10 seconds).
// If an operation is buffered for more than 1 second, throw an error.

const schema = new Schema({..}, { bufferTimeoutMS: 1000 });
option: capped
Mongoose supports MongoDBs capped collections. To specify the underlying MongoDB

collection be capped , set the capped option to the maximum size of the collection in bytes.
new Schema({..}, { capped: 1024 });
The capped option may also be set to an object if you want to pass additional options like max
or autoIndexId. In this case you must explicitly pass the size option, which is required.
new Schema({..}, { capped: { size: 1024, max: 1000, autoIndexId: true } });
option: collection
Mongoose by default produces a collection name by passing the model name to the
utils.toCollectionName method. This method pluralizes the name. Set this option if you need a
di erent name for your collection. so if ur model name is test, ur collection will be tests
const dataSchema = new Schema({..}, { collection: 'data' });
option: discriminatorKey
When you de ne a discriminator, Mongoose adds a path to your schema that stores which
discriminator a document is an instance of. By default, Mongoose adds an __t path, but you can
set discriminatorKey to overwrite this default.
const baseSchema = new Schema({}, { discriminatorKey: 'type' });

const BaseModel = mongoose.model('Test', baseSchema);
const personSchema = new Schema({ name: String });

const PersonModel = BaseModel.discriminator('Person', personSchema);
const doc = new PersonModel({ name: 'James T. Kirk' });

// Without `discriminatorKey`, Mongoose would store the discriminator
// key in `__t` instead of `type`
doc.type; // 'Person'
option: id
Mongoose assigns each of your schemas an id virtual getter by default which returns the
document's _id eld cast to a string, or in the case of ObjectIds, its hexString. If you don't want
an id getter added to your schema, you may disable it by passing this option at schema
construction time.
// default behavior
const schema = new Schema({ name: String });
const Page = mongoose.model('Page', schema);
const p = new Page({ name: 'mongodb.org' });
console.log(p.id); // '50341373e894ad16347efe01'
// disabled id
const schema = new Schema({ name: String }, { id: false });
console.log(p.id); // undefined
option: _id
Mongoose assigns each of your schemas an _id eld by default if one is not passed into the
Schema constructor. The type assigned is an ObjectId to coincide with MongoDB's default
behavior. If you don't want an _id added to your schema at all, you may disable it using this
option.
You can only use this option on subdocuments. Mongoose can't save a document without
knowing its id, so you will get an error if you try to save a document without an _id .
// default behavior
console.log(p); // { _id: '50341373e894ad16347efe01', name: 'mongodb.org' }
// disabled _id
const childSchema = new Schema({ name: String }, { _id: false });
const parentSchema = new Schema({ children: [childSchema] });
const Model = mongoose.model('Model', parentSchema); it returns a promise
Model.create({ children: [{ name: 'Luke' }] }, (error, doc) => {

// doc.children[0]._id will be undefined The create() function is a thin wrapper around the save() function.
}); The above create() call is equivalent to:
const doc = new User({ email: '[email protected]' });

await doc.save();
option: minimize
Mongoose will, by default, "minimize" schemas by removing empty objects.
const schema = new Schema({ name: String, inventory: {} });

const Character = mongoose.model('Character', schema);
// will store ìnventory` field if it is not empty

const frodo = new Character({ name: 'Frodo', inventory: { ringOfPower: 1 }});
await frodo.save();
let doc = await Character.findOne({ name: 'Frodo' }).lean();
doc.inventory; // { ringOfPower: 1 }
// will not store ìnventory` field if it is empty

const sam = new Character({ name: 'Sam', inventory: {}});
await sam.save();
doc = await Character.findOne({ name: 'Sam' }).lean();
doc.inventory; // undefined
This behavior can be overridden by setting minimize option to false . It will then store empty
objects.
const schema = new Schema({ name: String, inventory: {} }, { minimize: false });
const Character = mongoose.model('Character', schema);
// will store ìnventory` if empty

const sam = new Character({ name: 'Sam', inventory: {} });
await sam.save();
doc = await Character.findOne({ name: 'Sam' }).lean();
doc.inventory; // {}
To check whether an object is empty, you can use the $isEmpty() helper:
const sam = new Character({ name: 'Sam', inventory: {} });

sam.$isEmpty('inventory'); // true
sam.inventory.barrowBlade = 1;
sam.$isEmpty('inventory'); // false
option: read
Allows setting query#read options at the schema level, providing us a way to apply default
ReadPreferences to all queries derived from a model.
const schema = new Schema({..}, { read: 'primary' }); // also aliased as 'p'
const schema = new Schema({..}, { read: 'primaryPreferred' }); // aliased as 'pp'
const schema = new Schema({..}, { read: 'secondary' }); // aliased as 's'
const schema = new Schema({..}, { read: 'secondaryPreferred' }); // aliased as 'sp'
const schema = new Schema({..}, { read: 'nearest' }); // aliased as 'n'
The alias of each pref is also permitted so instead of having to type out 'secondaryPreferred' and
getting the spelling wrong, we can simply pass 'sp'.
The read option also allows us to specify tag sets. These tell the driver from which members of
the replica-set it should attempt to read. Read more about tag sets here and here.
NOTE: you may also specify the driver read preference strategy option when connecting:
// pings the replset members periodically to track network latency

const options = { replset: { strategy: 'ping' }};
mongoose.connect(uri, options);
const schema = new Schema({..}, { read: ['nearest', { disk: 'ssd' }] });

mongoose.model('JellyBean', schema);
option: writeConcern
Allows setting write concern at the schema level.
const schema = new Schema({ name: String }, {

writeConcern: {
w: 'majority',
j: true,
wtimeout: 1000
}
});
option: shardKey
The shardKey option is used when we have a sharded MongoDB architecture. Each sharded
collection is given a shard key which must be present in all insert/update operations. We just
need to set this schema option to the same shard key and we’ll be all set.
new Schema({ .. }, { shardKey: { tag: 1, name: 1 }})
Note that Mongoose does not send the shardcollection command for you. You must con gure
your shards yourself.
option: strict
The strict option, (enabled by default), ensures that values passed to our model constructor that
were not speci ed in our schema do not get saved to the db.
const thingSchema = new Schema({..})

const Thing = mongoose.model('Thing', thingSchema);
const thing = new Thing({ iAmNotInTheSchema: true });
thing.save(); // iAmNotInTheSchema is not saved to the db
// set to false..
const thingSchema = new Schema({..}, { strict: false });
const thing = new Thing({ iAmNotInTheSchema: true });
thing.save(); // iAmNotInTheSchema is now saved to the db!!
This also a ects the use of doc.set() to set a property value.

const thing = new Thing;
thing.set('iAmNotInTheSchema', true);
thing.save(); // iAmNotInTheSchema is not saved to the db
This value can be overridden at the model instance level by passing a second boolean argument:
const Thing = mongoose.model('Thing');

const thing = new Thing(doc, true); // enables strict mode
const thing = new Thing(doc, false); // disables strict mode
The strict option may also be set to "throw" which will cause errors to be produced instead
of dropping the bad data.
NOTE: Any key/val set on the instance that does not exist in your schema is always ignored,
regardless of schema option.

const thing = new Thing;
thing.iAmNotInTheSchema = true;
thing.save(); // iAmNotInTheSchema is never saved to the db
option: strictQuery
Mongoose supports a separate strictQuery option to avoid strict mode for query lters. This is
because empty query lters cause Mongoose to return all documents in the model, which can
cause issues.
const mySchema = new Schema({ field: Number }, { strict: true });

const MyModel = mongoose.model('Test', mySchema);
// Mongoose will filter out `notInSchema: 1` because `strict: true`, meaning this query will
// _all_ documents in the 'tests' collection
MyModel.find({ notInSchema: 1 });
The strict option does apply to updates. The strictQuery option is just for query lters.
// Mongoose will strip out `notInSchema` from the update if `strict` is

// not `false`
MyModel.updateMany({}, { $set: { notInSchema: 1 } });
Mongoose has a separate strictQuery option to toggle strict mode for the filter parameter
to queries.
const mySchema = new Schema({ field: Number }, {

strict: true,
strictQuery: false // Turn off strict mode for query filters
});
const MyModel = mongoose.model('Test', mySchema);
// Mongoose will not strip out `notInSchema: 1` because `strictQuery` is false
MyModel.find({ notInSchema: 1 });
In general, we do not recommend passing user-de ned objects as query lters:
// Don't do this!
const docs = await MyModel.find(req.query);
// Do this instead:
const docs = await MyModel.find({ name: req.query.name, age: req.query.age }).setOptions({ s
In Mongoose 6, strictQuery is equal to strict by default. However, you can override this
behavior globally:
// Set `strictQuery` to `false`, so Mongoose doesn't strip out non-schema

// query filter properties by default.
// This does **not** affect `strict`.
mongoose.set('strictQuery', false);
In Mongoose 7, strictQuery default value will be switched back to false . You can prepare for
the change by specifying:
// Set `strictQuery` to `false` to prepare for the change

mongoose.set('strictQuery', false);
// Set `strictQuery` to `true` to suppress the warning message

mongoose.set('strictQuery', true);
option: toJSON
Exactly the same as the toObject option but only applies when the document's toJSON method
is called.

schema.path('name').get(function (v) {
return v + ' is my name';
});
schema.set('toJSON', { getters: true, virtuals: false });
const M = mongoose.model('Person', schema);
const m = new M({ name: 'Max Headroom' });
console.log(m.toObject()); // { _id: 504e0cd7dd992d9be2f20b6f, name: 'Max Headroom' }
console.log(m.toJSON()); // { _id: 504e0cd7dd992d9be2f20b6f, name: 'Max Headroom is my name
// since we know toJSON is called whenever a js object is stringified:
console.log(JSON.stringify(m)); // { "_id": "504e0cd7dd992d9be2f20b6f", "name": "Max Headroo
To see all available toJSON/toObject options, read this.
option: toObject
Documents have a toObject method which converts the mongoose document into a plain
JavaScript object. This method accepts a few options. Instead of applying these options on a per-
document basis, we may declare the options at the schema level and have them applied to all of
the schema's documents by default.
To have all virtuals show up in your console.log output, set the toObject option to {
getters: true } :

schema.path('name').get(function(v) {
return v + ' is my name';
});
schema.set('toObject', { getters: true });
const m = new M({ name: 'Max Headroom' });
console.log(m); // { _id: 504e0cd7dd992d9be2f20b6f, name: 'Max Headroom is my name' }
To see all available toObject options, read this.
option: typeKey
By default, if you have an object with key 'type' in your schema, mongoose will interpret it as a
type declaration.
// Mongoose interprets this as 'loc is a String'

const schema = new Schema({ loc: { type: String, coordinates: [Number] } });
However, for applications like geoJSON, the 'type' property is important. If you want to control
which key mongoose uses to nd type declarations, set the 'typeKey' schema option.
const schema = new Schema({

// Mongoose interprets this as 'loc is an object with 2 keys, type and coordinates'
loc: { type: String, coordinates: [Number] },
// Mongoose interprets this as 'name is a String'
name: { $type: String }
}, { typeKey: '$type' }); // A '$type' key means this object is a type declaration
option: validateBeforeSave
By default, documents are automatically validated before they are saved to the database. This is
to prevent saving an invalid document. If you want to handle validation manually, and be able to
save objects which don't pass validation, you can set validateBeforeSave to false.

schema.set('validateBeforeSave', false);
schema.path('name').validate(function (value) {
return value != null;
});
const m = new M({ name: null });
m.validate(function(err) {
console.log(err); // Will tell you that null is not allowed.
});
m.save(); // Succeeds despite being invalid
option: versionKey
The versionKey is a property set on each document when rst created by Mongoose. This keys
value contains the internal revision of the document. The versionKey option is a string that
represents the path to use for versioning. The default is __v . If this con icts with your
application you can con gure as such:
const schema = new Schema({ name: 'string' });

const Thing = mongoose.model('Thing', schema);
const thing = new Thing({ name: 'mongoose v3' });
await thing.save(); // { __v: 0, name: 'mongoose v3' }
// customized versionKey
new Schema({..}, { versionKey: '_somethingElse' })
const thing = new Thing({ name: 'mongoose v3' });
thing.save(); // { _somethingElse: 0, name: 'mongoose v3' }
Note that Mongoose's default versioning is not a full optimistic concurrency solution. Mongoose's
default versioning only operates on arrays as shown below.
// 2 copies of the same document

const doc1 = await Model.findOne({ _id });
const doc2 = await Model.findOne({ _id });
// Delete first 3 comments from `doc1`

doc1.comments.splice(0, 3);
await doc1.save();
// The below `save()` will throw a VersionError, because you're trying to

// modify the comment at index 1, and the above `splice()` removed that
// comment.
doc2.set('comments.1.body', 'new comment');
await doc2.save();
If you need optimistic concurrency support for save() , you can set the optimisticConcurrency
option
Document versioning can also be disabled by setting the versionKey to false . DO NOT disable
versioning unless you know what you are doing.
new Schema({..}, { versionKey: false });

const thing = new Thing({ name: 'no versioning please' });
thing.save(); // { name: 'no versioning please' }
Mongoose only updates the version key when you use save() . If you use update() ,
findOneAndUpdate() , etc. Mongoose will not update the version key. As a workaround, you can
use the below middleware.
schema.pre('findOneAndUpdate', function() {
const update = this.getUpdate();
if (update.__v != null) {
delete update.__v;
}
const keys = ['$set', '$setOnInsert'];
for (const key of keys) {
if (update[key] != null && update[key].__v != null) {
delete update[key].__v;
if (Object.keys(update[key]).length === 0) {
delete update[key];
}
}
}
update.$inc = update.$inc || {};
update.$inc.__v = 1;
});
option: optimisticConcurrency
Optimistic concurrency is a strategy to ensure the document you're updating didn't change
between when you loaded it using find() or findOne() , and when you update it using
save() .
For example, suppose you have a House model that contains a list of photos , and a status
that represents whether this house shows up in searches. Suppose that a house that has status
'APPROVED' must have at least two photos . You might implement the logic of approving a
house document as shown below:
async function markApproved(id) {

const house = await House.findOne({ _id });
if (house.photos.length < 2) {
throw new Error('House must have at least two photos!');
}
house.status = 'APPROVED';
await house.save();
}
The markApproved() function looks right in isolation, but there might be a potential issue: what
if another function removes the house's photos between the findOne() call and the save()
call? For example, the below code will succeed:

}
const house2 = await House.findOne({ _id });

house2.photos = [];
await house2.save();
// Marks the house as 'APPROVED' even though it has 0 photos!

await house.save();
If you set the optimisticConcurrency option on the House model's schema, the above script
will throw an error.
const House = mongoose.model('House', Schema({

status: String,
photos: [String]
}, { optimisticConcurrency: true }));

}
const house2 = await House.findOne({ _id });

house2.photos = [];
await house2.save();
// Throws 'VersionError: No matching document found for id "..." version 0'

await house.save();
option: collation
Sets a default collation for every query and aggregation. Here's a beginner-friendly overview of
collations.

name: String
}, { collation: { locale: 'en_US', strength: 1 } });
const MyModel = db.model('MyModel', schema);
MyModel.create([{ name: 'val' }, { name: 'Val' }]).

then(() => {
return MyModel.find({ name: 'val' });
}).
then((docs) => {
// `docs` will contain both docs, because `strength: 1` means
// MongoDB will ignore case when matching.
});
option: timeseries
If you set the timeseries option on a schema, Mongoose will create a timeseries collection for
any model that you create from that schema.
const schema = Schema({ name: String, timestamp: Date, metadata: Object }, {

timeseries: {
timeField: 'timestamp',
metaField: 'metadata',
granularity: 'hours'
},
autoCreate: false,
expireAfterSeconds: 86400
});
// `Test` collection will be a timeseries collection

const Test = db.model('Test', schema);
option: skipVersioning
skipVersioning allows excluding paths from versioning (i.e., the internal revision will not be
incremented even if these paths are updated). DO NOT do this unless you know what you're
doing. For subdocuments, include this on the parent document using the fully quali ed path.
new Schema({..}, { skipVersioning: { dontVersionMe: true } });

thing.dontVersionMe.push('hey');
thing.save(); // version is not incremented
option: timestamps
The timestamps option tells Mongoose to assign createdAt and updatedAt elds to your
schema. The type assigned is Date.
By default, the names of the elds are createdAt and updatedAt . Customize the eld names by
setting timestamps.createdAt and timestamps.updatedAt .
The way timestamps works under the hood is:
If you create a new document, mongoose simply sets createdAt , and updatedAt to the
time of creation.
If you update a document, mongoose will add updatedAt to the $set object.
If you set upsert: true on an update operation, mongoose will use $setOnInsert
operator to add createdAt to the document in case the upsert operation resulted into a
new inserted document.
const thingSchema = new Schema({..}, { timestamps: { createdAt: 'created_at' } });

const thing = new Thing();
await thing.save(); // `created_at` & ùpdatedAt` will be included
// With updates, Mongoose will add ùpdatedAt` to `$set`

await Thing.updateOne({}, { $set: { name: 'Test' } });
// If you set upsert: true, Mongoose will add `created_at` to `$setOnInsert` as well
await Thing.findOneAndUpdate({}, { $set: { name: 'Test2' } });
// Mongoose also adds timestamps to bulkWrite() operations

// See https://mongoosejs.com/docs/api/model.html#model_Model-bulkWrite
await Thing.bulkWrite([
insertOne: {
document: {
name: 'Jean-Luc Picard',
ship: 'USS Stargazer'
// Mongoose will add `created_at` and ùpdatedAt`
}
},
updateOne: {
filter: { name: 'Jean-Luc Picard' },
update: {
$set: {
ship: 'USS Enterprise'
// Mongoose will add ùpdatedAt`
}
}
}
]);
By default, Mongoose uses new Date() to get the current time. If you want to overwrite the
function Mongoose uses to get the current time, you can set the timestamps.currentTime
option. Mongoose will call the timestamps.currentTime function whenever it needs to get the
current time.
const schema = Schema({

createdAt: Number,
updatedAt: Number,
name: String
}, {
// Make Mongoose use Unix time (seconds since Jan 1, 1970)
timestamps: { currentTime: () => Math.floor(Date.now() / 1000) }
});
option: pluginTags
Mongoose supports de ning global plugins, plugins that apply to all schemas.
// Add a `meta` property to all schemas

mongoose.plugin(function myPlugin(schema) {
schema.add({ meta: {} });
});
Sometimes, you may only want to apply a given plugin to some schemas. In that case, you can
add pluginTags to a schema:
const schema1 = new Schema({

name: String
}, { pluginTags: ['useMetaPlugin'] });

name: String
});
If you call plugin() with a tags option, Mongoose will only apply that plugin to schemas that
have a matching entry in pluginTags .
// Add a `meta` property to all schemas

mongoose.plugin(function myPlugin(schema) {
schema.add({ meta: {} });
}, { tags: ['useMetaPlugin'] });
option: selectPopulatedPaths
By default, Mongoose will automatically select() any populated paths for you, unless you
explicitly exclude them.
const bookSchema = new Schema({

title: 'String',
author: { type: 'ObjectId', ref: 'Person' }
});
const Book = mongoose.model('Book', bookSchema);
// By default, Mongoose will add àuthor` to the below `select()`.

await Book.find().select('title').populate('author');
// In other words, the below query is equivalent to the above

await Book.find().select('title author').populate('author');
To opt out of selecting populated elds by default, set selectPopulatedPaths to false in your
schema.
const bookSchema = new Schema({

title: 'String',
author: { type: 'ObjectId', ref: 'Person' }
}, { selectPopulatedPaths: false });
const Book = mongoose.model('Book', bookSchema);
// Because `selectPopulatedPaths` is false, the below doc will **not**

// contain an àuthor` property.
const doc = await Book.findOne().select('title').populate('author');
option: storeSubdocValidationError
For legacy reasons, when there is a validation error in subpath of a single nested schema,
Mongoose will record that there was a validation error in the single nested schema path as well.
For example:
const childSchema = new Schema({ name: { type: String, required: true } });
const parentSchema = new Schema({ child: childSchema });
const Parent = mongoose.model('Parent', parentSchema);
// Will contain an error for both 'child.name' _and_ 'child'

new Parent({ child: {} }).validateSync().errors;
Set the storeSubdocValidationError to false on the child schema to make Mongoose only
reports the parent error.
const childSchema = new Schema({

name: { type: String, required: true }
}, { storeSubdocValidationError: false }); // <-- set on the child schema
const parentSchema = new Schema({ child: childSchema });
// Will only contain an error for 'child.name'

new Parent({ child: {} }).validateSync().errors;
With ES6 Classes
Schemas have a loadClass() method that you can use to create a Mongoose schema from an
ES6 class:
ES6 class methods become Mongoose methods

ES6 class statics become Mongoose statics
ES6 getters and setters become Mongoose virtuals
Here's an example of using loadClass() to create a schema from an ES6 class:
class MyClass {
myMethod() { return 42; }
static myStatic() { return 42; }
get myVirtual() { return 42; }
}
const schema = new mongoose.Schema();

schema.loadClass(MyClass);
console.log(schema.methods); // { myMethod: [Function: myMethod] }

console.log(schema.statics); // { myStatic: [Function: myStatic] }
console.log(schema.virtuals); // { myVirtual: VirtualType { ... } }
Pluggable
Schemas are also pluggable which allows us to package up reusable features into plugins that
can be shared with the community or just between your projects.
Further Reading
Here's an alternative introduction to Mongoose schemas.
To get the most out of MongoDB, you need to learn the basics of MongoDB schema design. SQL
schema design (third normal form) was designed to minimize storage costs, whereas MongoDB
schema design is about making common queries as fast as possible. The 6 Rules of Thumb for
MongoDB Schema Design blog series is an excellent resource for learning the basic rules for
making your queries fast.
Users looking to master MongoDB schema design in Node.js should look into The Little MongoDB
Schema Design Book by Christian Kvalheim, the original author of the MongoDB Node.js driver.
This book shows you how to implement performant schemas for a laundry list of use cases,
including e-commerce, wikis, and appointment bookings.
Next Up
Now that we've covered Schemas , let's take a look at SchemaTypes.

mongoose
SchemaTypes
SPONSOR #native_company# — #native_desc#
SchemaTypes handle de nition of path defaults, validation, getters, setters, eld selection
defaults for queries, and other general characteristics for Mongoose document properties.
What is a SchemaType?
The type Key
SchemaType Options
Usage Notes
Getters
Custom Types
The schema.path() Function
Further Reading
What is a SchemaType?
You can think of a Mongoose schema as the con guration object for a Mongoose model. A
SchemaType is then a con guration object for an individual property. A SchemaType says what
type a given path should have, whether it has any getters/setters, and what values are valid for
that path.

schema.path('name') instanceof mongoose.SchemaType; // true
schema.path('name') instanceof mongoose.Schema.Types.String; // true
schema.path('name').instance; // 'String'
A SchemaType is di erent from a type. In other words, mongoose.ObjectId !==

mongoose.Types.ObjectId . A SchemaType is just a con guration object for Mongoose. An
instance of the mongoose.ObjectId SchemaType doesn't actually create MongoDB ObjectIds, it
is just a con guration for a path in a schema.
The following are all the valid SchemaTypes in Mongoose. Mongoose plugins can also add
custom SchemaTypes like int32. Check out Mongoose's plugins search to nd plugins.
String
Number
Date
Bu er
Boolean
Mixed
ObjectId
Array
Decimal128
Map
Schema
Example

name: String,
binary: Buffer,
living: Boolean,
updated: { type: Date, default: Date.now },
age: { type: Number, min: 18, max: 65 },
mixed: Schema.Types.Mixed,
_someId: Schema.Types.ObjectId,
decimal: Schema.Types.Decimal128,
array: [],
ofString: [String],
ofNumber: [Number],
arrays of specific type
ofDates: [Date],
ofBuffer: [Buffer],
ofBoolean: [Boolean],
ofMixed: [Schema.Types.Mixed],
ofObjectId: [Schema.Types.ObjectId],
ofArrays: [[]],
ofArrayOfNumbers: [[Number]],
nested: {
stuff: { type: String, lowercase: true, trim: true }
},
map: Map,
mapOfString: {
type: Map,
of: String
}
})
// example use
const m = new Thing;

m.name = 'Statue of Liberty';
m.age = 125;
m.updated = new Date;
m.binary = Buffer.alloc(0);
m.living = false;
m.mixed = { any: { thing: 'i want' } };
m.markModified('mixed');
m._someId = new mongoose.Types.ObjectId;
m.array.push(1);
m.ofString.push("strings!");
m.ofNumber.unshift(1,2,3,4); The unshift() method adds one or more elements to the beginning of an
array and returns the new length of the array.
m.ofDates.addToSet(new Date); The $addToSet operator adds a value to an array unless the value is
m.ofBuffer.pop(); already present, in which case $addToSet does nothing to that array.
m.ofMixed = [1, [], 'three', { four: 5 }];
m.nested.stuff = 'good';
m.map = new Map([['key', 'value']]);
m.save(callback);
The type Key
type is a special property in Mongoose schemas. When Mongoose nds a nested property
named type in your schema, Mongoose assumes that it needs to de ne a SchemaType with the
given type.
// 3 string SchemaTypes: 'name', 'nested.firstName', 'nested.lastName'

name: { type: String },
nested: {
firstName: { type: String },
lastName: { type: String }
}
}); object with two properties firstname and lastname`
As a consequence, you need a little extra work to de ne a property named type in your schema.
For example, suppose you're building a stock portfolio app, and you want to store the asset's
type (stock, bond, ETF, etc.). Naively, you might de ne your schema as shown below:
const holdingSchema = new Schema({

// You might expect àsset` to be an object that has 2 properties,
// but unfortunately `type` is special in Mongoose so mongoose
// interprets this schema to mean that àsset` is a string
asset: {
type: String,
ticker: String
}
});
However, when Mongoose sees type: String , it assumes that you mean asset should be a
string, not an object with a property type . The correct way to de ne an object with a property
type is shown below.
const holdingSchema = new Schema({

asset: {
// Workaround to make sure Mongoose knows àsset` is an object
// and àsset.type` is a string, rather than thinking àsset`
// is a string.
type: { type: String },
ticker: String
} define all other stuff
}); like validator in this
object
SchemaType Options
You can declare a schema type using the type directly, or an object with a type property.

test: String // `test` is a path of type String
});

// The `test` object contains the "SchemaType options"
test: { type: String } // `test` is a path of type string
});
In addition to the type property, you can specify additional properties for a path. For example, if
you want to lowercase a string before saving:

test: {
type: String,
lowercase: true // Always convert `test` to lowercase
}
});
You can add any property you want to your SchemaType options. Many plugins rely on custom
SchemaType options. For example, the mongoose-autopopulate plugin automatically populates
paths if you set autopopulate: true in your SchemaType options. Mongoose comes with
support for several built-in SchemaType options, like lowercase in the above example.
The lowercase option only works for strings. There are certain options which apply for all
schema types, and some that apply for speci c schema types.
All Schema Types
required : boolean or function, if true adds a required validator for this property
default : Any or function, sets a default value for the path. If the value is a function, the
return value of the function is used as the default.
select : boolean, speci es default projections for queries
validate : function, adds a validator function for this property
get : function, de nes a custom getter for this property using Object.defineProperty() .
set : function, de nes a custom setter for this property using Object.defineProperty() .
alias : string, mongoose >= 4.10.0 only. De nes a virtual with the given name that
gets/sets this path.
immutable : boolean, de nes path as immutable. Mongoose prevents you from changing
immutable paths unless the parent document has isNew: true .
transform : function, Mongoose calls this function when you call Document#toJSON()
function, including when you JSON.stringify() a document.
const numberSchema = new Schema({

integerOnly: {
type: Number,
get: v => Math.round(v),
set: v => Math.round(v),
alias: 'i'
}
});
const Number = mongoose.model('Number', numberSchema);
const doc = new Number();

doc.integerOnly = 2.001;
value returned by the
doc.integerOnly; // 2
setter is stored in the
doc.i; // 2 integerOnly property
doc.i = 3.001;
doc.integerOnly; // 3
doc.i; // 3
Indexes
You can also de ne MongoDB indexes using schema type options.
index : boolean, whether to de ne an index on this property.

unique : boolean, whether to de ne a unique index on this property.
sparse : boolean, whether to de ne a sparse index on this property.

test: {
type: String,
index: true,
unique: true // Unique index. If you specify ùnique: true`
// specifying ìndex: true` is optional if you do ùnique: true`
}
});
String
lowercase : boolean, whether to always call .toLowerCase() on the value

uppercase : boolean, whether to always call .toUpperCase() on the value
trim : boolean, whether to always call .trim() on the value
match : RegExp, creates a validator that checks if the value matches the given regular
expression
enum : Array, creates a validator that checks if the value is in the given array.
minLength : Number, creates a validator that checks if the value length is not less than the
given number
maxLength : Number, creates a validator that checks if the value length is not greater than
the given number
populate : Object, sets default populate options
Number
min : Number, creates a validator that checks if the value is greater than or equal to the
given minimum.
max : Number, creates a validator that checks if the value is less than or equal to the given
maximum.
enum : Array, creates a validator that checks if the value is strictly equal to one of the values
in the given array.
Date
min : Date, creates a validator that checks if the value is greater than or equal to the given
minimum.
max : Date, creates a validator that checks if the value is less than or equal to the given
maximum.
expires : Number or String, creates a TTL index with the value expressed in seconds.
ObjectId
Usage Notes
String
To declare a path as a string, you may use either the String global constructor or the string
'String' .
const schema1 = new Schema({ name: String }); // name will be cast to string
const schema2 = new Schema({ name: 'String' }); // Equivalent
const Person = mongoose.model('Person', schema2);
If you pass an element that has a toString() function, Mongoose will call it, unless the element
is an array or the toString() function is strictly equal to Object.prototype.toString() .
new Person({ name: 42 }).name; // "42" as a string

new Person({ name: { toString: () => 42 } }).name; // "42" as a string
// "undefined", will get a cast error if you `save()` this document

new Person({ name: { foo: 42 } }).name;
Number
To declare a path as a number, you may use either the Number global constructor or the string
'Number' .
const schema1 = new Schema({ age: Number }); // age will be cast to a Number
const schema2 = new Schema({ age: 'Number' }); // Equivalent
const Car = mongoose.model('Car', schema2);
There are several types of values that will be successfully cast to a Number.
new Car({ age: '15' }).age; // 15 as a Number

new Car({ age: true }).age; // 1 as a Number
new Car({ age: false }).age; // 0 as a Number
new Car({ age: { valueOf: () => 83 } }).age; // 83 as a Number
If you pass an object with a valueOf() function that returns a Number, Mongoose will call it and
assign the returned value to the path.
The values null and undefined are not cast.
NaN, strings that cast to NaN, arrays, and objects that don't have a valueOf() function will all
result in a CastError once validated, meaning that it will not throw on initialization, only when
validated. validation is done while saving in the database
Dates
Built-in Date methods are not hooked into the mongoose change tracking logic which in English
means that if you use a Date in your document and modify it with a method like setMonth() ,
mongoose will be unaware of this change and doc.save() will not persist this modi cation. If
you must modify Date types using built-in methods, tell mongoose about the change with
doc.markModified('pathToYourDate') before saving.
const Assignment = mongoose.model('Assignment', { dueDate: Date });

Assignment.findOne(function (err, doc) {
doc.dueDate.setMonth(3);
doc.save(callback); // THIS DOES NOT SAVE YOUR CHANGE
doc.markModified('dueDate');
doc.save(callback); // works
})
Bu er
To declare a path as a Bu er, you may use either the Buffer global constructor or the string
'Buffer' .
const schema1 = new Schema({ binData: Buffer }); // binData will be cast to a Buffer
const schema2 = new Schema({ binData: 'Buffer' }); // Equivalent
const Data = mongoose.model('Data', schema2);
Mongoose will successfully cast the below values to bu ers.
const file1 = new Data({ binData: 'test'}); // {"type":"Buffer","data":[116,101,115,116]}

const file2 = new Data({ binData: 72987 }); // {"type":"Buffer","data":[27]}
const file4 = new Data({ binData: { type: 'Buffer', data: [1, 2, 3]}}); // {"type":"Buffer",
Mixed
An "anything goes" SchemaType. Mongoose will not do any casting on mixed paths. You can
de ne a mixed path using Schema.Types.Mixed or by passing an empty object literal. The
following are equivalent.
const Any = new Schema({ any: {} });

const Any = new Schema({ any: Object });
const Any = new Schema({ any: Schema.Types.Mixed });
const Any = new Schema({ any: mongoose.Mixed });
Since Mixed is a schema-less type, you can change the value to anything else you like, but
Mongoose loses the ability to auto detect and save those changes. To tell Mongoose that the
value of a Mixed type has changed, you need to call doc.markModified(path) , passing the path
to the Mixed type you just changed.
To avoid these side-e ects, a Subdocument path may be used instead.
person.anything = { x: [3, 4, { y: "changed" }] };

person.markModified('anything');
person.save(); // Mongoose will save changes to ànything`.
ObjectIds
An ObjectId is a special type typically used for unique identi ers. Here's how you declare a
schema with a path driver that is an ObjectId:
const mongoose = require('mongoose');

const carSchema = new mongoose.Schema({ driver: mongoose.ObjectId });
ObjectId is a class, and ObjectIds are objects. However, they are often represented as strings.
When you convert an ObjectId to a string using toString() , you get a 24-character hexadecimal
string:
const Car = mongoose.model('Car', carSchema);
const car = new Car();

car.driver = new mongoose.Types.ObjectId();
typeof car.driver; // 'object'

car.driver instanceof mongoose.Types.ObjectId; // true
car.driver.toString(); // Something like "5e1a0651741b255ddda996c4"
Boolean
Booleans in Mongoose are plain JavaScript booleans. By default, Mongoose casts the below
values to true :
true
'true'
1
'1'
'yes'
Mongoose casts the below values to false :
false
'false'
0
'0'
'no'
Any other value causes a CastError. You can modify what values Mongoose converts to true or
false using the convertToTrue and convertToFalse properties, which are JavaScript sets.
const M = mongoose.model('Test', new Schema({ b: Boolean }));

console.log(new M({ b: 'nay' }).b); // undefined
// Set { false, 'false', 0, '0', 'no' }

console.log(mongoose.Schema.Types.Boolean.convertToFalse);
mongoose.Schema.Types.Boolean.convertToFalse.add('nay');
console.log(new M({ b: 'nay' }).b); // false
Arrays
Mongoose supports arrays of SchemaTypes and arrays of subdocuments. Arrays of SchemaTypes

are also called primitive arrays, and arrays of subdocuments are also called document arrays.
const ToySchema = new Schema({ name: String });

const ToyBoxSchema = new Schema({
toys: [ToySchema],
buffers: [Buffer],
strings: [String],
numbers: [Number]
// ... etc
});
Arrays are special because they implicitly have a default value of [] (empty array).
const ToyBox = mongoose.model('ToyBox', ToyBoxSchema);

console.log((new ToyBox()).toys); // []
To overwrite this default, you need to set the default value to undefined
const ToyBoxSchema = new Schema({

toys: {
type: [ToySchema],
default: undefined
}
});
Note: specifying an empty array is equivalent to Mixed . The following all create arrays of Mixed :
const Empty1 = new Schema({ any: [] });

const Empty2 = new Schema({ any: Array });
const Empty3 = new Schema({ any: [Schema.Types.Mixed] });
const Empty4 = new Schema({ any: [{}] });
Maps
New in Mongoose 5.1.0
A MongooseMap is a subclass of JavaScript's Map class. In these docs, we'll use the terms 'map'
and MongooseMap interchangeably. In Mongoose, maps are how you create a nested document
with arbitrary keys.
Note: In Mongoose Maps, keys must be strings in order to store the document in MongoDB.
const userSchema = new Schema({

// `socialMediaHandles` is a map whose values are strings. A map's
// keys are always strings. You specify the type of values using òf`.
socialMediaHandles: {
type: Map,
of: String
}
});
const User = mongoose.model('User', userSchema);

// Map { 'github' => 'vkarpov15', 'twitter' => '@code_barbarian' }
console.log(new User({
github: 'vkarpov15',
twitter: '@code_barbarian'
} automatically gets converted to str
}).socialMediaHandles);
The above example doesn't explicitly declare github or twitter as paths, but, since
socialMediaHandles is a map, you can store arbitrary key/value pairs. However, since
socialMediaHandles is a map, you must use .get() to get the value of a key and .set() to
set the value of a key.
const user = new User({

socialMediaHandles: {}
});
// Good
user.socialMediaHandles.set('github', 'vkarpov15');
// Works too
user.set('socialMediaHandles.twitter', '@code_barbarian');
// Bad, the `myspace` property will **not** get saved
user.socialMediaHandles.myspace = 'fail';
// 'vkarpov15'
console.log(user.socialMediaHandles.get('github'));
// '@code_barbarian'
console.log(user.get('socialMediaHandles.twitter'));
// undefined
user.socialMediaHandles.github;
// Will only save the 'github' and 'twitter' properties

user.save();
Map types are stored as BSON objects in MongoDB. Keys in a BSON object are ordered, so this
means the insertion order property of maps is maintained.
Mongoose supports a special $* syntax to populate all elements in a map. For example, suppose
your socialMediaHandles map contains a ref :

type: Map,
of: new Schema({
handle: String,
oauth: {
type: ObjectId,
ref: 'OAuth'
}
})
}
});
To populate every socialMediaHandles entry's oauth property, you should populate on

socialMediaHandles.$*.oauth :
const user = await User.findOne().populate('socialMediaHandles.$*.oauth');
Getters
Getters are like virtuals for paths de ned in your schema. For example, let's say you wanted to
store user pro le pictures as relative paths and then add the hostname in your application.
Below is how you would structure your userSchema :
const root = 'https://s3.amazonaws.com/mybucket';

name: String,
picture: {
type: String,
get: v => `${root}${v}`
}
});
const doc = new User({ name: 'Val', picture: '/123.png' });

doc.picture; // 'https://s3.amazonaws.com/mybucket/123.png'
doc.toObject({ getters: false }).picture; // '/123.png'
Generally, you only use getters on primitive paths as opposed to arrays or subdocuments.
Because getters override what accessing a Mongoose path returns, declaring a getter on an
object may remove Mongoose change tracking for that path.

arr: [{ url: String }]
});
// Bad, don't do this!

schema.path('arr').get(v => {
return v.map(el => Object.assign(el, { url: root + el.url }));
});
// Later
doc.arr.push({ key: String });
doc.arr[0]; // 'undefined' because every `doc.arr` creates a new array!
Instead of declaring a getter on the array as shown above, you should declare a getter on the
url string as shown below. If you need to declare a getter on a nested document or array, be
very careful!

arr: [{ url: String }]
});
// Good, do this instead of declaring a getter on àrr`

schema.path('arr.0.url').get(v => `${root}${v}`);
Schemas
To declare a path as another schema, set type to the sub-schema's instance.
To set a default value based on the sub-schema's shape, simply set a default value, and the value
will be cast based on the sub-schema's de nition before being set during document creation.
const subSchema = new mongoose.Schema({

// some schema definition here
});
const schema = new mongoose.Schema({

data: {
type: subSchema
default: {}
}
});
Creating Custom Types
Mongoose can also be extended with custom SchemaTypes. Search the plugins site for
compatible types like mongoose-long, mongoose-int32, and other types.
Read more about creating custom SchemaTypes here.
The `schema.path()` Function
The schema.path() function returns the instantiated schema type for a given path.
const sampleSchema = new Schema({ name: { type: String, required: true } });
console.log(sampleSchema.path('name'));
// Output looks like:
/**
* SchemaString {
* enumValues: [],
* regExp: null,
* path: 'name',
* instance: 'String',
* validators: ...
*/
You can use this function to inspect the schema type for a given path, including what validators it
has and what the type is.
Further Reading
An Introduction to Mongoose SchemaTypes

Mongoose Schema Types
Next Up
Now that we've covered SchemaTypes , let's take a look at Connections.

mongoose
Connections
You can connect to MongoDB with the mongoose.connect() method.
mongoose.connect('mongodb://127.0.0.1:27017/myapp');
This is the minimum needed to connect the myapp database running locally on the default port
(27017). If connecting fails on your machine, try using 127.0.0.1 instead of localhost .
You can also specify several more parameters in the uri :
mongoose.connect('mongodb://username:password@host:port/database?options...');
See the mongodb connection string spec for more details.
Bu ering
Error Handling
Options
Connection String Options
Connection Events
A note about keepAlive
Server Selection
Replica Set Connections
Replica Set Host Names
Multi-mongos support
Multiple connections
Connection Pools
Operation Bu ering
Mongoose lets you start using your models immediately, without waiting for mongoose to
establish a connection to MongoDB.
const MyModel = mongoose.model('Test', new Schema({ name: String }));
// Works
MyModel.findOne(function(error, result) { /* ... */ });
That's because mongoose bu ers model function calls internally. This bu ering is convenient,
but also a common source of confusion. Mongoose will not throw any errors by default if you use
a model without connecting.

// Will just hang until mongoose successfully connects
MyModel.findOne(function(error, result) { /* ... */ });
setTimeout(function() {
}, 60000);
To disable bu ering, turn o the bufferCommands option on your schema. If you have
bufferCommands on and your connection is hanging, try turning bufferCommands o to see if
you haven't opened a connection properly. You can also disable bufferCommands globally:
mongoose.set('bufferCommands', false);
Note that bu ering is also responsible for waiting until Mongoose creates collections if you use
the autoCreate option. If you disable bu ering, you should also disable the autoCreate option
and use createCollection() to create capped collections or collections with collations.

name: String
}, {
capped: { size: 1024 },
bufferCommands: false,
autoCreate: false // disable àutoCreate` since `bufferCommands` is false
});

// Explicitly create the collection before using it
// so the collection is capped.
await Model.createCollection();
Error Handling
There are two classes of errors that can occur with a Mongoose connection.
Error on initial connection. If initial connection fails, Mongoose will emit an 'error' event and
the promise mongoose.connect() returns will reject. However, Mongoose will not
automatically try to reconnect.
Error after initial connection was established. Mongoose will attempt to reconnect, and it
will emit an 'error' event.
To handle initial connection errors, you should use .catch() or try/catch with async/await.
error is thrown by this promise
mongoose.connect('mongodb://127.0.0.1:27017/test').
catch(error => handleError(error));
// Or:
try {
await mongoose.connect('mongodb://127.0.0.1:27017/test');
} catch (error) {
handleError(error);
}
To handle errors after initial connection was established, you should listen for error events on
the connection. However, you still need to handle initial connection errors as shown above.
mongoose.connection.on('error', err => {

logError(err);
});
Note that Mongoose does not necessarily emit an 'error' event if it loses connectivity to
MongoDB. You should listen to the disconnected event to report when Mongoose is
disconnected from MongoDB.
Options
The connect method also accepts an options object which will be passed on to the underlying
MongoDB driver.
A full list of options can be found on the MongoDB Node.js driver docs for MongoClientOptions .
Mongoose passes options to the driver without modi cation, modulo a few exceptions that are
explained below.
bufferCommands - This is a mongoose-speci c option (not passed to the MongoDB driver)

that disables Mongoose's bu ering mechanism
user / pass - The username and password for authentication. These options are
Mongoose-speci c, they are equivalent to the MongoDB driver's auth.username and
auth.password options.
autoIndex - By default, mongoose will automatically build indexes de ned in your schema
when it connects. This is great for development, but not ideal for large production
deployments, because index builds can cause performance degradation. If you set
autoIndex to false, mongoose will not automatically build indexes for any model
associated with this connection.
dbName - Speci es which database to connect to and overrides any database speci ed in
the connection string. This is useful if you are unable to specify a default database in the
connection string like with some mongodb+srv syntax connections.
Below are some of the options that are important for tuning Mongoose.
promiseLibrary - Sets the underlying driver's promise library.

maxPoolSize - The maximum number of sockets the MongoDB driver will keep open for
this connection. By default, maxPoolSize is 100. Keep in mind that MongoDB only allows
one operation per socket at a time, so you may want to increase this if you nd you have a
few slow queries that are blocking faster queries from proceeding. See Slow Trains in
MongoDB and Node.js. You may want to decrease maxPoolSize if you are running into
connection limits.
minPoolSize - The minimum number of sockets the MongoDB driver will keep open for
this connection. The MongoDB driver may close sockets that have been inactive for some
time. You may want to increase minPoolSize if you expect your app to go through long idle
times and want to make sure your sockets stay open to avoid slow trains when activity picks
up.
socketTimeoutMS - How long the MongoDB driver will wait before killing a socket due to
inactivity after initial connection. A socket may be inactive because of either no activity or a
long-running operation. This is set to 30000 by default, you should set this to 2-3x your
longest running operation if you expect some of your database operations to run longer
than 20 seconds. This option is passed to Node.js socket#setTimeout() function after the
MongoDB driver successfully completes.
family - Whether to connect using IPv4 or IPv6. This option passed to Node.js'
dns.lookup() function. If you don't specify this option, the MongoDB driver will try IPv6
rst and then IPv4 if IPv6 fails. If your mongoose.connect(uri) call takes a long time, try
mongoose.connect(uri, { family: 4 })
authSource - The database to use when authenticating with user and pass . In MongoDB,
users are scoped to a database. If you are getting an unexpected login failure, you may
need to set this option.
serverSelectionTimeoutMS - The MongoDB driver will try to nd a server to send any
given operation to, and keep retrying for serverSelectionTimeoutMS milliseconds. If not
set, the MongoDB driver defaults to using 30000 (30 seconds).
heartbeatFrequencyMS - The MongoDB driver sends a heartbeat every
heartbeatFrequencyMS to check on the status of the connection. A heartbeat is subject to
serverSelectionTimeoutMS , so the MongoDB driver will retry failed heartbeats for up to
30 seconds by default. Mongoose only emits a 'disconnected' event after a heartbeat has
failed, so you may want to decrease this setting to reduce the time between when your
server goes down and when Mongoose emits 'disconnected' . We recommend you do not
set this setting below 1000, too many heartbeats can lead to performance degradation.
The serverSelectionTimeoutMS option also handles how long mongoose.connect() will retry
initial connection before erroring out. mongoose.connect() will retry for 30 seconds by default
(default serverSelectionTimeoutMS ) before erroring out. To get faster feedback on failed
operations, you can reduce serverSelectionTimeoutMS to 5000 as shown below.
Example:
const options = {
autoIndex: false, // Don't build indexes
maxPoolSize: 10, // Maintain up to 10 socket connections
serverSelectionTimeoutMS: 5000, // Keep trying to send operations for 5 seconds
socketTimeoutMS: 45000, // Close sockets after 45 seconds of inactivity
family: 4 // Use IPv4, skip trying IPv6
};
See this page for more information about connectTimeoutMS and socketTimeoutMS
Callback
The connect() function also accepts a callback parameter and returns a promise.
mongoose.connect(uri, options, function(error) {

// Check error in initial connection. There is no 2nd param to the callback.
});
// Or using promises
mongoose.connect(uri, options).then(
() => { /** ready to use. The `mongoose.connect()` promise resolves to mongoose instance.
err => { /** handle initial connection error */ }
);
Connection String Options
You can also specify driver options in your connection string as parameters in the query string
portion of the URI. This only applies to options passed to the MongoDB driver. You can't set
Mongoose-speci c options like bufferCommands in the query string.
mongoose.connect('mongodb://127.0.0.1:27017/test?connectTimeoutMS=1000&bufferCommands=false&
// The above is equivalent to:
mongoose.connect('mongodb://127.0.0.1:27017/test', {
connectTimeoutMS: 1000
// Note that mongoose will **not** pull `bufferCommands` from the query string
});
The disadvantage of putting options in the query string is that query string options are harder to
read. The advantage is that you only need a single con guration option, the URI, rather than
separate options for socketTimeoutMS , connectTimeoutMS , etc. Best practice is to put options
that likely di er between development and production, like replicaSet or ssl , in the
connection string, and options that should remain constant, like connectTimeoutMS or
maxPoolSize , in the options object.
The MongoDB docs have a full list of supported connection string options. Below are some
options that are often useful to set in the connection string because they are closely associated
with the hostname and authentication information.
authSource - The database to use when authenticating with user and pass . In MongoDB,
users are scoped to a database. If you are getting an unexpected login failure, you may
need to set this option.
family - Whether to connect using IPv4 or IPv6. This option passed to Node.js'
dns.lookup() function. If you don't specify this option, the MongoDB driver will try IPv6
rst and then IPv4 if IPv6 fails. If your mongoose.connect(uri) call takes a long time, try
mongoose.connect(uri, { family: 4 })
Connection Events
Connections inherit from Node.js' EventEmitter class, and emit events when something
happens to the connection, like losing connectivity to the MongoDB server. Below is a list of
events that a connection may emit.
connecting : Emitted when Mongoose starts making its initial connection to the MongoDB
server
connected : Emitted when Mongoose successfully makes its initial connection to the
MongoDB server, or when Mongoose reconnects after losing connectivity. May be emitted
multiple times if Mongoose loses connectivity.
open : Emitted after 'connected' and onOpen is executed on all of this connection's
models.
disconnecting : Your app called Connection#close() to disconnect from MongoDB
disconnected : Emitted when Mongoose lost connection to the MongoDB server. This
event may be due to your code explicitly closing the connection, the database server
crashing, or network connectivity issues.
close : Emitted after Connection#close() successfully closes the connection. If you call
conn.close() , you'll get both a 'disconnected' event and a 'close' event.
reconnected : Emitted if Mongoose lost connectivity to MongoDB and successfully
reconnected. Mongoose attempts to automatically reconnect when it loses connection to
the database.
error : Emitted if an error occurs on a connection, like a parseError due to malformed
data or a payload larger than 16MB.
fullsetup : Emitted when you're connecting to a replica set and Mongoose has
successfully connected to the primary and at least one secondary.
all : Emitted when you're connecting to a replica set and Mongoose has successfully
connected to all servers speci ed in your connection string.
When you're connecting to a single MongoDB server (a "standalone"), Mongoose will emit
'disconnected' if it gets disconnected from the standalone server, and 'connected' if it
successfully connects to the standalone. In a replica set, Mongoose will emit 'disconnected' if it
loses connectivity to the replica set primary, and 'connected' if it manages to reconnect to the
replica set primary.
A note about keepAlive
For long running applications, it is often prudent to enable keepAlive with a number of
milliseconds. Without it, after some period of time you may start to see "connection closed"
errors for what seems like no reason. If so, after reading this, you may decide to enable
keepAlive :
mongoose.connect(uri, { keepAlive: true, keepAliveInitialDelay: 300000 });
keepAliveInitialDelay is the number of milliseconds to wait before initiating keepAlive on

the socket. keepAlive is true by default since mongoose 5.2.0.
Replica Set Connections
To connect to a replica set you pass a comma delimited list of hosts to connect to rather than a
single host.
mongoose.connect('mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:por
For example:
mongoose.connect('mongodb://user:[email protected]:27017,host2.com:27017,host3.com:27017/testdb')
To connect to a single node replica set, specify the replicaSet option.
mongoose.connect('mongodb://host1:port1/?replicaSet=rsName');
Server Selection
The underlying MongoDB driver uses a process known as server selection to connect to
MongoDB and send operations to MongoDB. If the MongoDB driver can't nd a server to send an
operation to after serverSelectionTimeoutMS , you'll get the below error:
MongoTimeoutError: Server selection timed out after 30000 ms
You can con gure the timeout using the serverSelectionTimeoutMS option to
mongoose.connect() :
mongoose.connect(uri, {
serverSelectionTimeoutMS: 5000 // Timeout after 5s instead of 30s
});
A MongoTimeoutError has a reason property that explains why server selection timed out. For
example, if you're connecting to a standalone server with an incorrect password, reason will
contain an "Authentication failed" error.
const uri = 'mongodb+srv://username:[email protected]/' +

'test?retryWrites=true&w=majority';
// Prints "MongoServerError: bad auth Authentication failed."
mongoose.connect(uri, {
serverSelectionTimeoutMS: 5000
}).catch(err => console.log(err.reason));
Replica Set Host Names
MongoDB replica sets rely on being able to reliably gure out the domain name for each
member. On Linux and OSX, the MongoDB server uses the output of the hostname command to
gure out the domain name to report to the replica set. This can cause confusing errors if you're
connecting to a remote MongoDB replica set running on a machine that reports its hostname as
localhost :
// Can get this error even if your connection string doesn't include
// `localhost` if `rs.conf()` reports that one replica set member has
// `localhost` as its host name.
MongooseServerSelectionError: connect ECONNREFUSED localhost:27017
If you're experiencing a similar error, connect to the replica set using the mongo shell and run the
rs.conf() command to check the host names of each replica set member. Follow this page's
instructions to change a replica set member's host name.
You can also check the reason.servers property of MongooseServerSelectionError to see

what the MongoDB Node driver thinks the state of your replica set is. The reason.servers
property contains a map of server descriptions.
if (err.name === 'MongooseServerSelectionError') {

// Contains a Map describing the state of your replica set. For example:
// Map(1) {
// 'localhost:27017' => ServerDescription {
// address: 'localhost:27017',
// type: 'Unknown',
// ...
// }
// }
console.log(err.reason.servers);
}
Multi-mongos support
You can also connect to multiple mongos instances for high availability in a sharded cluster. You
do not need to pass any special options to connect to multiple mongos in mongoose 5.x.
// Connect to 2 mongos servers

mongoose.connect('mongodb://mongosA:27501,mongosB:27501', cb);
Multiple connections
So far we've seen how to connect to MongoDB using Mongoose's default connection. Mongoose
creates a default connection when you call mongoose.connect() . You can access the default
connection using mongoose.connection .
You may need multiple connections to MongoDB for several reasons. One reason is if you have
multiple databases or multiple MongoDB clusters. Another reason is to work around slow trains.
The mongoose.createConnection() function takes the same arguments as
mongoose.connect() and returns a new connection.
const conn = mongoose.createConnection('mongodb://[username:password@]host1[:port1][,host2[:
This connection object is then used to create and retrieve models. Models are always scoped to a
single connection.
const UserModel = conn.model('User', userSchema);
If you use multiple connections, you should make sure you export schemas, not models.
Exporting a model from a le is called the export model pattern. The export model pattern is
limited because you can only use one connection.
const userSchema = new Schema({ name: String, email: String });
// The alternative to the export model pattern is the export schema pattern.
module.exports = userSchema;
// Because if you export a model as shown below, the model will be scoped
// to Mongoose's default connection.
// module.exports = mongoose.model('User', userSchema);
If you use the export schema pattern, you still need to create models somewhere. There are two
common patterns. First is to export a connection and register the models on the connection in
the le:
// connections/fast.js
const conn = mongoose.createConnection(process.env.MONGODB_URI);

conn.model('User', require('../schemas/user'));
module.exports = conn;
// connections/slow.js

conn.model('PageView', require('../schemas/pageView'));
module.exports = conn;
Another alternative is to register connections with a dependency injector or another inversion of

control (IOC) pattern.
module.exports = function connectionFactory() {

conn.model('PageView', require('../schemas/pageView'));
return conn;
};
Connection Pools
Each connection , whether created with mongoose.connect or mongoose.createConnection

are all backed by an internal con gurable connection pool defaulting to a maximum size of 100.
Adjust the pool size using your connection options:
// With object options

mongoose.createConnection(uri, { maxPoolSize: 10 });
// With connection string options

const uri = 'mongodb://127.0.0.1:27017/test?maxPoolSize=10';
mongoose.createConnection(uri);
Next Up
Now that we've covered connections, let's take a look at models.

mongoose
Models
Models are fancy constructors compiled from Schema de nitions. An instance of a model is
called a document. Models are responsible for creating and reading documents from the
underlying MongoDB database.
Compiling your rst model

Constructing Documents
Querying
Deleting
Updating
Change Streams
Views
Compiling your rst model

When you call mongoose.model() on a schema, Mongoose compiles a model for you.
const schema = new mongoose.Schema({ name: 'string', size: 'string' });

const Tank = mongoose.model('Tank', schema);
The rst argument is the singular name of the collection your model is for. Mongoose
automatically looks for the plural, lowercased version of your model name. Thus, for the example
above, the model Tank is for the tanks collection in the database.
Note: The .model() function makes a copy of schema . Make sure that you've added everything
you want to schema , including hooks, before calling .model() !
Constructing Documents
An instance of a model is called a document. Creating them and saving to the database is easy.
const Tank = mongoose.model('Tank', yourSchema);
const small = new Tank({ size: 'small' });

small.save(function (err) {
if (err) return handleError(err);
// saved!
});
// or
Tank.create({ size: 'small' }, function (err, small) {

// saved!
});
// or, for inserting large batches of documents

Tank.insertMany([{ size: 'small' }], function(err) {
});
Note that no tanks will be created/removed until the connection your model uses is open. Every
model has an associated connection. When you use mongoose.model() , your model will use the
default mongoose connection.
mongoose.connect('mongodb://127.0.0.1/gettingstarted');
If you create a custom connection, use that connection's model() function instead.
const connection = mongoose.createConnection('mongodb://127.0.0.1:27017/test');

const Tank = connection.model('Tank', yourSchema);
Querying
Finding documents is easy with Mongoose, which supports the rich query syntax of MongoDB.
Documents can be retrieved using a model 's nd, ndById, ndOne, or where static functions.
Tank.find({ size: 'small' }).where('createdDate').gt(oneYearAgo).exec(callback);
See the chapter on queries for more details on how to use the Query api.
Deleting
Models have static deleteOne() and deleteMany() functions for removing all documents
matching the given filter .
Tank.deleteOne({ size: 'large' }, function (err) {

// deleted at most one tank document
});
Updating
Each model has its own update method for modifying documents in the database without
returning them to your application. See the API docs for more detail.
Tank.updateOne({ size: 'large' }, { name: 'T-90' }, function(err, res) {

// Updated at most one doc, `res.nModified` contains the number
// of docs that MongoDB updated
});
If you want to update a single document in the db and return it to your application, use
ndOneAndUpdate instead.
Change Streams
Change streams provide a way for you to listen to all inserts and updates going through your
MongoDB database. Note that change streams do not work unless you're connected to a
MongoDB replica set. This means that if you want to use change streams, your MongoDB deployment must be a replica
set, and not just a single instance. This is because change streams rely on the ability to detect
changes by comparing the data between replica set members, so it only works in replica set
configuration.
async function run() {
// Create a new mongoose model
const personSchema = new mongoose.Schema({
name: String
});
// Create a change stream. The 'change' event gets emitted when there's a
// change in the database
Person.watch().
on('change', data => console.log(new Date(), data));
// Insert a doc, will trigger the change stream handler above

console.log(new Date(), 'Inserting doc');
await Person.create({ name: 'Axl Rose' });
}
The output from the above async function will look like what you see below.
2018-05-11T15:05:35.467Z 'Inserting doc'

2018-05-11T15:05:35.487Z 'Inserted doc'
2018-05-11T15:05:35.491Z { _id: { _data: ... },
operationType: 'insert',
fullDocument: { _id: 5af5b13fe526027666c6bf83, name: 'Axl Rose', __v: 0 },
ns: { db: 'test', coll: 'Person' },
documentKey: { _id: 5af5b13fe526027666c6bf83 } }
You can read more about change streams in mongoose in this blog post.
Views
MongoDB Views are essentially read-only collections that contain data computed from other
collections using aggregations. In Mongoose, you should de ne a separate Model for each of
your Views. You can also create a View using createCollection() .
The following example shows how you can create a new RedactedUser View on a User Model
that hides potentially sensitive information, like name and email.
// Make sure to disable àutoCreate` and àutoIndex` for Views,

// because you want to create the collection manually.
name: String,
email: String,
roles: [String]
}, { autoCreate: false, autoIndex: false });
const RedactedUser = mongoose.model('RedactedUser', userSchema);
// First, create the User model's underlying collection...

await User.createCollection();
// Then create the `RedactedUser` model's underlying collection
// as a View.
await RedactedUser.createCollection({
viewOn: 'users', // Set `viewOn` to the collection name, **not** model name.
pipeline: [
{
$set: {
name: { $concat: [{ $substr: ['$name', 0, 3] }, '...'] },
email: { $concat: [{ $substr: ['$email', 0, 3] }, '...'] }
}
}
]
});
await User.create([
{ name: 'John Smith', email: '[email protected]', roles: ['user'] },
{ name: 'Bill James', email: '[email protected]', roles: ['user', 'admin'] }
]);
// [{ _id: ..., name: 'Bil...', email: 'bil...', roles: ['user', 'admin'] }]

console.log(await RedactedUser.find({ roles: 'admin' }));
Note that Mongoose does not currently enforce that Views are read-only. If you attempt to
save() a document from a View, you will get an error from the MongoDB server.
Yet more
The API docs cover many additional methods available like count, mapReduce, aggregate, and
more.
Next Up
Now that we've covered Models , let's take a look at Documents.
mongoose
Documents
Mongoose documents represent a one-to-one mapping to documents as stored in MongoDB.

Each document is an instance of its Model.
Documents vs Models
Retrieving
Updating Using save()
Updating Using Queries
Validating
Overwriting
Documents vs Models
Document and Model are distinct classes in Mongoose. The Model class is a subclass of the
Document class. When you use the Model constructor, you create a new document.

const doc = new MyModel();
doc instanceof MyModel; // true

doc instanceof mongoose.Model; // true
doc instanceof mongoose.Document; // true
In Mongoose, a "document" generally means an instance of a model. You should not have to
create an instance of the Document class without going through a model.
Retrieving
When you load documents from MongoDB using model functions like findOne() , you get a
Mongoose document back.
const doc = await MyModel.findOne();
doc instanceof MyModel; // true

doc instanceof mongoose.Model; // true
doc instanceof mongoose.Document; // true
Updating Using save()

Mongoose documents track changes. You can modify a document using vanilla JavaScript
assignments and Mongoose will convert it into MongoDB update operators.
doc.name = 'foo';
// Mongoose sends an ùpdateOne({ _id: doc._id }, { $set: { name: 'foo' } })`

// to MongoDB.
await doc.save();
The save() method returns a promise. If save() succeeds, the promise resolves to the
document that was saved.
doc.save().then(savedDoc => {
savedDoc === doc; // true
});
If the document with the corresponding _id is not found, Mongoose will report a
DocumentNotFoundError :
const doc = await MyModel.findOne();
// Delete the document so Mongoose won't be able to save changes

await MyModel.deleteOne({ _id: doc._id });
doc.name = 'foo';
await doc.save(); // Throws DocumentNotFoundError
Updating Using Queries

The save() function is generally the right way to update a document with Mongoose. With
save() , you get full validation and middleware.
For cases when save() isn't exible enough, Mongoose lets you create your own MongoDB
updates with casting, middleware, and limited validation.
// Update all documents in the `mymodels` collection

does validation
await MyModel.updateMany({}, { $set: { name: 'foo' } }); happens?
Note that update() , updateMany() , findOneAndUpdate() , etc. do not execute save()

middleware. If you need save middleware and full validation, rst query for the document and
then save() it. the data is not validated when we update a document,validation is only done while saving
Validating
Documents are casted and validated before they are saved. Mongoose rst casts values to the
speci ed type and then validates them. Internally, Mongoose calls the document's validate()
method before saving.
const schema = new Schema({ name: String, age: { type: Number, min: 0 } });
const Person = mongoose.model('Person', schema);
let p = new Person({ name: 'foo', age: 'bar' });

// Cast to Number failed for value "bar" at path "age"
await p.validate();
let p2 = new Person({ name: 'foo', age: -1 });

// Path àge` (-1) is less than minimum allowed value (0).
await p2.validate();
Mongoose also supports limited validation on updates using the runValidators option.
Mongoose casts parameters to query functions like findOne() , updateOne() by default.
However, Mongoose does not run validation on query function parameters by default. You need
to set runValidators: true for Mongoose to validate.
means by default type is checked of the
data ,but validations are not checked like min,
maxLength,validate etc
// Cast to number failed for value "bar" at path "age"
await Person.updateOne({}, { age: 'bar' });
// Path àge` (-1) is less than minimum allowed value (0).

await Person.updateOne({}, { age: -1 }, { runValidators: true });
Read the validation guide for more details.
Overwriting
There are 2 di erent ways to overwrite a document (replacing all keys in the document). One way
is to use the Document#overwrite() function followed by save() .
const doc = await Person.findOne({ _id });
// Sets `name` and unsets all other properties

doc.overwrite({ name: 'Jean-Luc Picard' });
await doc.save();
The other way is to use Model.replaceOne() .
// Sets `name` and unsets all other properties

await Person.replaceOne({ _id }, { name: 'Jean-Luc Picard' });
Next Up
Now that we've covered Documents, let's take a look at Subdocuments.

mongoose
Subdocuments
Subdocuments are documents embedded in other documents. In Mongoose, this means you can
nest schemas in other schemas. Mongoose has two distinct notions of subdocuments: arrays of
subdocuments and single nested subdocuments.
const childSchema = new Schema({ name: 'string' });

// Array of subdocuments
children: [childSchema],
// Single nested subdocuments
child: childSchema
});
Note that populated documents are not subdocuments in Mongoose. Subdocument data is
embedded in the top-level document. Referenced documents are separate top-level documents.
const childSchema = new Schema({ name: 'string' });

const Child = mongoose.model('Child', childSchema);

child: {
type: mongoose.ObjectId,
ref: 'Child'
}
});
const doc = await Parent.findOne().populate('child');

// NOT a subdocument. `doc.child` is a separate top-level document.
doc.child;
What is a Subdocument?
Subdocuments versus Nested Paths
Subdocument Defaults
Finding a Subdocument
Adding Subdocs to Arrays
Removing Subdocs
Parents of Subdocs
Alternate declaration syntax for arrays
What is a Subdocument?
Subdocuments are similar to normal documents. Nested schemas can have middleware, custom
validation logic, virtuals, and any other feature top-level schemas can use. The major di erence is
that subdocuments are not saved individually, they are saved whenever their top-level parent
document is saved.

const parent = new Parent({ children: [{ name: 'Matt' }, { name: 'Sarah' }] })
parent.children[0].name = 'Matthew';
// `parent.children[0].save()` is a no-op, it triggers middleware but

// does **not** actually save the subdocument. You need to save the parent
// doc.
parent.save(callback);
Subdocuments have save and validate middleware just like top-level documents. Calling
save() on the parent document triggers the save() middleware for all its subdocuments, and
the same for validate() middleware.
childSchema.pre('save', function (next) {

if ('invalid' == this.name) {
return next(new Error('#sadpanda'));
}
next();
});
const parent = new Parent({ children: [{ name: 'invalid' }] });

parent.save(function (err) {
console.log(err.message) // #sadpanda
});
Subdocuments' pre('save') and pre('validate') middleware execute before the top-level

document's pre('save') but after the top-level document's pre('validate') middleware.
This is because validating before save() is actually a piece of built-in middleware.
// Below code will print out 1-4 in order

const childSchema = new mongoose.Schema({ name: 'string' });
childSchema.pre('validate', function(next) {
console.log('2');
next();
});
childSchema.pre('save', function(next) {
console.log('3');
next();
});
const parentSchema = new mongoose.Schema({

child: childSchema
});
parentSchema.pre('validate', function(next) {
console.log('1');
next();
});
parentSchema.pre('save', function(next) {
console.log('4');
next();
});
Subdocuments versus Nested Paths
In Mongoose, nested paths are subtly di erent from subdocuments. For example, below are two
schemas: one with child as a subdocument, and one with child as a nested path.
// Subdocument
const subdocumentSchema = new mongoose.Schema({
child: new mongoose.Schema({ name: String, age: Number })
});
const Subdoc = mongoose.model('Subdoc', subdocumentSchema);
// Nested path
const nestedSchema = new mongoose.Schema({
child: { name: String, age: Number }
});
const Nested = mongoose.model('Nested', nestedSchema);
These two schemas look similar, and the documents in MongoDB will have the same structure
with both schemas. But there are a few Mongoose-speci c di erences:
First, instances of Nested never have child === undefined . You can always set subproperties
of child , even if you don't set the child property. But instances of Subdoc can have child
=== undefined .
const doc1 = new Subdoc({});

doc1.child === undefined; // true
doc1.child.name = 'test'; // Throws TypeError: cannot read property...
const doc2 = new Nested({});

doc2.child === undefined; // false
console.log(doc2.child); // Prints 'MongooseDocument { undefined }'
doc2.child.name = 'test'; // Works
Subdocument Defaults
Subdocument paths are unde ned by default, and Mongoose does not apply subdocument
defaults unless you set the subdocument path to a non-nullish value.

child: new mongoose.Schema({
name: String,
age: {
type: Number,
default: 0
}
})
});
// Note that the àge` default has no effect, because `child`

// is ùndefined`.
const doc = new Subdoc();
doc.child; // undefined
However, if you set doc.child to any object, Mongoose will apply the age default if necessary.
doc.child = {};
// Mongoose applies the àge` default:
doc.child.age; // 0
Mongoose applies defaults recursively, which means there's a nice workaround if you want to
make sure Mongoose applies subdocument defaults: make the subdocument path default to an
empty object.
const childSchema = new mongoose.Schema({

name: String,
age: {
type: Number,
default: 0
}
});
child: {
type: childSchema,
default: () => ({})
}
});
// Note that Mongoose sets àge` to its default value 0, because

// `child` defaults to an empty object and Mongoose applies
// defaults to that empty object.
const doc = new Subdoc();
doc.child; // { age: 0 }
Finding a Subdocument
Each subdocument has an _id by default. Mongoose document arrays have a special id method
for searching a document array to nd a document with a given _id .
const doc = parent.children.id(_id);
Adding Subdocs to Arrays
MongooseArray methods such as push, unshift, addToSet, and others cast arguments to their
proper types transparently:
const Parent = mongoose.model('Parent');

const parent = new Parent();
// create a comment
parent.children.push({ name: 'Liesl' });
const subdoc = parent.children[0];
console.log(subdoc) // { _id: '501d86090d371bab2c0341c5', name: 'Liesl' }
subdoc.isNew; // true
if (err) return handleError(err)
console.log('Success!');
});
You can also create a subdocument without adding it to an array by using the create() method
of Document Arrays.
const newdoc = parent.children.create({ name: 'Aaron' });
Removing Subdocs
Each subdocument has its own remove method. For an array subdocument, this is equivalent to
calling .pull() on the subdocument. For a single nested subdocument, remove() is equivalent
to setting the subdocument to null .
// Equivalent to `parent.children.pull(_id)`
parent.children.id(_id).remove();
// Equivalent to `parent.child = null`
parent.child.remove();
console.log('the subdocs were removed');
});
Parents of Subdocs
Sometimes, you need to get the parent of a subdoc. You can access the parent using the
parent() function.

docArr: [{ name: String }],
singleNested: new Schema({ name: String })
});
const doc = new Model({

docArr: [{ name: 'foo' }],
singleNested: { name: 'bar' }
});
doc.singleNested.parent() === doc; // true

doc.docArr[0].parent() === doc; // true
If you have a deeply nested subdoc, you can access the top-level document using the
ownerDocument() function.

level1: new Schema({
level2: new Schema({
test: String
})
})
});
const doc = new Model({ level1: { level2: 'test' } });
doc.level1.level2.parent() === doc; // false

doc.level1.level2.parent() === doc.level1; // true
doc.level1.level2.ownerDocument() === doc; // true
Alternate declaration syntax for arrays
If you create a schema with an array of objects, Mongoose will automatically convert the object to
a schema for you:

children: [{ name: 'string' }]
});
// Equivalent
children: [new Schema({ name: 'string' })]
});
Next Up
Now that we've covered Subdocuments, let's take a look at querying.

mongoose
Queries
Mongoose models provide several static helper functions for CRUD operations. Each of these
functions returns a mongoose Query object.
Model.deleteMany()
Model.deleteOne()
Model.find()
Model.findById()
Model.findByIdAndDelete()
Model.findByIdAndRemove()
Model.findByIdAndUpdate()
Model.findOne()
Model.findOneAndDelete()
Model.findOneAndRemove()
Model.findOneAndReplace()
Model.findOneAndUpdate()
Model.replaceOne()
Model.updateMany()
Model.updateOne()
A mongoose query can be executed in one of two ways. First, if you pass in a callback function,
Mongoose will execute the query asynchronously and pass the results to the callback .
A query also has a .then() function, and thus can be used as a promise.
Executing
Queries are Not Promises
References to other documents
Streaming
Versus Aggregation
Executing
When executing a query with a callback function, you specify your query as a JSON document.
The JSON document's syntax is the same as the MongoDB shell.
const Person = mongoose.model('Person', yourSchema);
// find each person with a last name matching 'Ghost', selecting the `name` and òccupation
Person.findOne({ 'name.last': 'Ghost' }, 'name occupation', function (err, person) {
// Prints "Space Ghost is a talk show host".
console.log('%s %s is a %s.', person.name.first, person.name.last,
person.occupation);
});
Mongoose executed the query and passed the results to callback . All callbacks in Mongoose
use the pattern: callback(error, result) . If an error occurs executing the query, the error
parameter will contain an error document, and result will be null. If the query is successful, the
error parameter will be null, and the result will be populated with the results of the query.
Anywhere a callback is passed to a query in Mongoose, the callback follows the pattern
callback(error, results) . What results is depends on the operation: For findOne() it is a
potentially-null single document, find() a list of documents, count() the number of
documents, update() the number of documents a ected, etc. The API docs for Models provide
more detail on what is passed to the callbacks.
Now let's look at what happens when no callback is passed:
// find each person with a last name matching 'Ghost'

const query = Person.findOne({ 'name.last': 'Ghost' });
// selecting the `name` and òccupation` fields

query.select('name occupation');
// execute the query at a later time

query.exec(function (err, person) {
// Prints "Space Ghost is a talk show host."
console.log('%s %s is a %s.', person.name.first, person.name.last,
person.occupation);
});
In the above code, the query variable is of type Query. A Query enables you to build up a query
using chaining syntax, rather than specifying a JSON object. The below 2 examples are equivalent.
// With a JSON doc

Person.
find({
occupation: /host/,
Not in Json format
'name.last': 'Ghost',
age: { $gt: 17, $lt: 66 },
likes: { $in: ['vaporizing', 'talking'] }
}).
limit(10).
sort({ occupation: -1 }).
select({ name: 1, occupation: 1 }).
exec(callback);
// Using query builder

Person.
find({ occupation: /host/ }).
where('name.last').equals('Ghost').
where('age').gt(17).lt(66).
where('likes').in(['vaporizing', 'talking']).
limit(10).
sort('-occupation').
select('name occupation').
exec(callback);
A full list of Query helper functions can be found in the API docs.
Queries are Not Promises
Mongoose queries are not promises. They have a .then() function for co and async/await as a
convenience. However, unlike promises, calling a query's .then() can execute the query
multiple times.
For example, the below code will execute 3 updateMany() calls, one because of the callback, and
two because .then() is called twice.
const q = MyModel.updateMany({}, { isDeleted: true }, function() {

console.log('Update 1');
});
q.then(() => console.log('Update 2'));

q.then(() => console.log('Update 3'));
Don't mix using callbacks and promises with queries, or you may end up with duplicate
operations. That's because passing a callback to a query function immediately executes the
query, and calling then() executes the query again.
Mixing promises and callbacks can lead to duplicate entries in arrays. For example, the below
code inserts 2 entries into the tags array, not just 1.
const BlogPost = mongoose.model('BlogPost', new Schema({

title: String,
tags: [String]
}));
// Because there's both àwait` **and** a callback, this ùpdateOne()` executes twice
// and thus pushes the same string into `tags` twice.
const update = { $push: { tags: ['javascript'] } };
await BlogPost.updateOne({ title: 'Introduction to Promises' }, update, (err, res) => {
console.log(res);
});
References to other documents
There are no joins in MongoDB but sometimes we still want references to documents in other
collections. This is where population comes in. Read more about how to include documents from
other collections in your query results here.
Streaming
You can stream query results from MongoDB. You need to call the Query#cursor() function to
return an instance of QueryCursor.
const cursor = Person.find({ occupation: /host/ }).cursor();
for (let doc = await cursor.next(); doc != null; doc = await cursor.next()) {
console.log(doc); // Prints documents one at a time
}
Iterating through a Mongoose query using async iterators also creates a cursor.
for await (const doc of Person.find()) {

console.log(doc); // Prints documents one at a time
}
Cursors are subject to cursor timeouts. By default, MongoDB will close your cursor after 10
minutes and subsequent next() calls will result in a MongoServerError: cursor id 123 not
found error. To override this, set the noCursorTimeout option on your cursor.
// MongoDB won't automatically close this cursor after 10 minutes.

const cursor = Person.find().cursor().addCursorFlag('noCursorTimeout', true);
However, cursors can still time out because of session idle timeouts. So even a cursor with
noCursorTimeout set will still time out after 30 minutes of inactivity. You can read more about
working around session idle timeouts in the MongoDB documentation.
Versus Aggregation
Aggregation can do many of the same things that queries can. For example, below is how you can
use aggregate() to nd docs where name.last = 'Ghost' :
const docs = await Person.aggregate([{ $match: { 'name.last': 'Ghost' } }]);
However, just because you can use aggregate() doesn't mean you should. In general, you
should use queries where possible, and only use aggregate() when you absolutely need to.
Unlike query results, Mongoose does not hydrate() aggregation results. Aggregation results are
always POJOs, not Mongoose documents.
const docs = await Person.aggregate([{ $match: { 'name.last': 'Ghost' } }]);
docs[0] instanceof mongoose.Document; // false
Also, unlike query lters, Mongoose also doesn't cast aggregation pipelines. That means you're
responsible for ensuring the values you pass in to an aggregation pipeline have the correct type.
const doc = await Person.findOne();
const idString = doc._id.toString();
// Finds the `Person`, because Mongoose casts ìdString` to an ObjectId

const queryRes = await Person.findOne({ _id: idString });
// Does **not** find the `Person`, because Mongoose doesn't cast aggregation
// pipelines.
const aggRes = await Person.aggregate([{ $match: { _id: idString } }])
Sorting
Sorting is how you can ensure you query results come back in the desired order.

age: Number
});

for (let i = 0; i < 10; i++) { no callback means
await Person.create({ age: i }); query is not executed
} at the first time so we
await
await Person.find().sort({ age: -1 }); // returns age starting from 10 as the first entry
await Person.find().sort({ age: 1 }); // returns age starting from 0 as the first entry
When sorting with mutiple elds, the order of the sort keys determines what key MongoDB
server sorts by rst.

age: Number,
name: String,
weight: Number
});

const iterations = 5;
for (let i = 0; i < iterations; i++) {
await Person.create({
age: Math.abs(2-i),
name: 'Test'+i,
weight: Math.floor(Math.random() * 100) + 1
});
}
await Person.find().sort({ age: 1, weight: -1 }); // returns age starting from 0, but while
You can view the output of a single run of this block below. As you can see, age is sorted from 0
to 2 but when age is equal, sorts by weight.
[
{
_id: new ObjectId("63a335a6b9b6a7bfc186cb37"),
age: 0,
name: 'Test2',
weight: 67,
__v: 0
},
{
age: 1,
name: 'Test1',
weight: 99,
__v: 0
},
{
age: 1,
name: 'Test3',
weight: 73,
__v: 0
},
{
age: 2,
name: 'Test0',
weight: 65,
__v: 0
},
{
_id: new ObjectId("63a335a6b9b6a7bfc186cb3b"),
age: 2,
name: 'Test4',
weight: 62,
__v: 0
}
]
Next Up
Now that we've covered Queries , let's take a look at Validation.

mongoose
Validation
Before we get into the speci cs of validation syntax, please keep the following rules in mind:
Validation is de ned in the SchemaType

Validation is middleware. Mongoose registers validation as a pre('save') hook on every
schema by default.
You can disable automatic validation before save by setting the validateBeforeSave option
You can manually run validation using doc.validate(callback) or doc.validateSync()
You can manually mark a eld as invalid (causing validation to fail) by using
doc.invalidate(...)
Validators are not run on unde ned values. The only exception is the required validator.
Validation is asynchronously recursive; when you call Model#save, sub-document validation
is executed as well. If an error occurs, your Model#save callback receives it
Validation is customizable

name: {
type: String,
required: true
}
});
const Cat = db.model('Cat', schema);
// This cat has no name :(

const cat = new Cat();
let error;
try {
await cat.save();
} catch (err) {
error = err;
}
assert.equal(error.errors['name'].message,
'Path `name` is required.');
error = cat.validateSync();
assert.equal(error.errors['name'].message,
'Path `name` is required.');
Built-in Validators
Custom Error Messages
The unique Option is Not a Validator
Custom Validators
Async Custom Validators
Validation Errors
Cast Errors
Global SchemaType Validation
Required Validators On Nested Objects
Update Validators
Update Validators and this
Update Validators Only Run On Updated Paths
Update Validators Only Run For Some Operations
Built-in Validators
Mongoose has several built-in validators.
All SchemaTypes have the built-in required validator. The required validator uses the
SchemaType's checkRequired() function to determine if the value satis es the required
validator.
Numbers have min and max validators.
Strings have enum , match , minLength , and maxLength validators.
Each of the validator links above provide more information about how to enable them and
customize their error messages.
const breakfastSchema = new Schema({

eggs: {
type: Number,
min: [6, 'Too few eggs'],
max: 12
},
bacon: {
type: Number,
required: [true, 'Why no bacon?']
},
drink: {
type: String,
enum: ['Coffee', 'Tea'],
required: function() {
return this.bacon > 3;
}
}
});
const Breakfast = db.model('Breakfast', breakfastSchema);
const badBreakfast = new Breakfast({

eggs: 2,
bacon: 0,
drink: 'Milk'
});
let error = badBreakfast.validateSync();
assert.equal(error.errors['eggs'].message,
'Too few eggs');
assert.ok(!error.errors['bacon']);
assert.equal(error.errors['drink'].message,
'`Milk` is not a valid enum value for path `drink`.');
badBreakfast.bacon = 5;
badBreakfast.drink = null;
error = badBreakfast.validateSync();
assert.equal(error.errors['drink'].message, 'Path `drink` is required.');
badBreakfast.bacon = null;
error = badBreakfast.validateSync();
assert.equal(error.errors['bacon'].message, 'Why no bacon?');
Custom Error Messages
You can con gure the error message for individual validators in your schema. There are two
equivalent ways to set the validator error message:
Array syntax: min: [6, 'Must be at least 6, got {VALUE}']

Object syntax: enum: { values: ['Coffee', 'Tea'], message: '{VALUE} is not
supported' }
Mongoose also supports rudimentary templating for error messages. Mongoose replaces
{VALUE} with the value being validated.
const breakfastSchema = new Schema({

eggs: {
type: Number,
min: [6, 'Must be at least 6, got {VALUE}'],
max: 12
},
drink: {
type: String,
enum: {
values: ['Coffee', 'Tea'],
message: '{VALUE} is not supported'
}
}
});
const Breakfast = db.model('Breakfast', breakfastSchema);
const badBreakfast = new Breakfast({

eggs: 2,
drink: 'Milk'
});
const error = badBreakfast.validateSync();
assert.equal(error.errors['eggs'].message,
'Must be at least 6, got 2');
assert.equal(error.errors['drink'].message, 'Milk is not supported');
The unique Option is Not a Validator
A common gotcha for beginners is that the unique option for schemas is not a validator. It's a
convenient helper for building MongoDB unique indexes. See the FAQ for more information.
const uniqueUsernameSchema = new Schema({

username: {
type: String,
unique: true
}
});
const U1 = db.model('U1', uniqueUsernameSchema);
const U2 = db.model('U2', uniqueUsernameSchema);
const dup = [{ username: 'Val' }, { username: 'Val' }];

U1.create(dup, err => {
// Race condition! This may save successfully, depending on whether
// MongoDB built the index before writing the 2 docs.
});
// You need to wait for Mongoose to finish building the ùnique`

// index before writing. You only need to build indexes once for
// a given collection, so you normally don't need to do this
// in production. But, if you drop the database between tests,
// you will need to use ìnit()` to wait for the index build to finish.
U2.init().
then(() => U2.create(dup)).
catch(error => {
// Will error, but will *not* be a mongoose validation error, it will be
// a duplicate key error.
// See: https://masteringjs.io/tutorials/mongoose/e11000-duplicate-key
assert.ok(error);
assert.ok(!error.errors);
assert.ok(error.message.indexOf('duplicate key error') !== -1);
});
Custom Validators
If the built-in validators aren't enough, you can de ne custom validators to suit your needs.
Custom validation is declared by passing a validation function. You can nd detailed instructions
on how to do this in the SchemaType#validate() API docs.

phone: {
type: String,
validate: {
validator: function(v) {
return /\d{3}-\d{3}-\d{4}/.test(v);
},
message: props => `${props.value} is not a valid phone number!`
},
required: [true, 'User phone number required']
}
});
const User = db.model('user', userSchema);

const user = new User();
let error;
user.phone = '555.0123';
error = user.validateSync();
assert.equal(error.errors['phone'].message,
'555.0123 is not a valid phone number!');
user.phone = '';
assert.equal(error.errors['phone'].message,
'User phone number required');
user.phone = '201-555-0123';
// Validation succeeds! Phone number is defined
// and fits `DDD-DDD-DDDD`
assert.equal(error, null);
Async Custom Validators
Custom validators can also be asynchronous. If your validator function returns a promise (like an
async function), mongoose will wait for that promise to settle. If the returned promise rejects, or
ful lls with the value false , Mongoose will consider that a validation error.

name: {
type: String,
// You can also make a validator async by returning a promise.if validate func returns true its mean
validate: () => Promise.reject(new Error('Oops!')) no error
},
email: {
type: String,
// There are two ways for an promise-based async validator to fail:
// 1) If the promise rejects, Mongoose assumes the validator failed with the given error
// 2) If the promise resolves to `false`, Mongoose assumes the validator failed and crea
validate: {
validator: () => Promise.resolve(false),
message: 'Email validation failed'
}
}
});
const User = db.model('User', userSchema);

const user = new User();
user.email = '[email protected]';
user.name = 'test';
let error;
try {
await user.validate();
if a promise gets rejected promise does not return the error,
} catch (err) { but error is thrown which is catched in the catch() block or .catch()
error = err; in try block we can use await
}
assert.ok(error);
assert.equal(error.errors['name'].message, 'Oops!');
assert.equal(error.errors['email'].message, 'Email validation failed');
Validation Errors
Errors returned after failed validation contain an errors object whose values are
ValidatorError objects. Each ValidatorError has kind , path , value , and message properties.
A ValidatorError also may have a reason property. If an error was thrown in the validator, this
property will contain the error that was thrown.
const toySchema = new Schema({

color: String,
name: String
});
const validator = function(value) {

return /red|white|gold/i.test(value);
};
toySchema.path('color').validate(validator,
'Color `{VALUE}` not valid', 'Invalid color');
toySchema.path('name').validate(function(v) {
if (v !== 'Turbo Man') {
throw new Error('Need to get a Turbo Man for Christmas');
}
return true;
}, 'Name `{VALUE}` is not valid');
const Toy = db.model('Toy', toySchema);
const toy = new Toy({ color: 'Green', name: 'Power Ranger' });
let error;
try {
await toy.save();
} catch(err) {
error = err;
}
// èrror` is a ValidationError object

// èrror.errors.color` is a ValidatorError object
assert.equal(error.errors.color.message, 'Color `Green` not valid');
assert.equal(error.errors.color.kind, 'Invalid color');
assert.equal(error.errors.color.path, 'color');
assert.equal(error.errors.color.value, 'Green');
// If your validator throws an exception, mongoose will use the error

// message. If your validator returns `false`,
// mongoose will use the 'Name `Power Ranger` is not valid' message.
assert.equal(error.errors.name.message,
'Need to get a Turbo Man for Christmas');
assert.equal(error.errors.name.value, 'Power Ranger');
// If your validator threw an error, the `reason` property will contain
// the original error thrown, including the original stack trace.
assert.equal(error.errors.name.reason.message,
'Need to get a Turbo Man for Christmas');
assert.equal(error.name, 'ValidationError');
Cast Errors
Before running validators, Mongoose attempts to coerce values to the correct type. This process
is called casting the document. If casting fails for a given path, the error.errors object will
contain a CastError object.
Casting runs before validation, and validation does not run if casting fails. That means your
custom validators may assume v is null , undefined , or an instance of the type speci ed in
your schema.
const vehicleSchema = new mongoose.Schema({

numWheels: { type: Number, max: 18 }
});
const Vehicle = db.model('Vehicle', vehicleSchema);
const doc = new Vehicle({ numWheels: 'not a number' });

const err = doc.validateSync();
err.errors['numWheels'].name; // 'CastError'
// 'Cast to Number failed for value "not a number" at path "numWheels"'
err.errors['numWheels'].message;
Global SchemaType Validation
In addition to de ning custom validators on individual schema paths, you can also con gure a
custom validator to run on every instance of a given SchemaType . For example, the following
code demonstrates how to make empty string '' an invalid value for all string paths.
// Add a custom validator to all strings

mongoose.Schema.Types.String.set('validate', v => v == null || v > 0);

name: String,
email: String
});
const User = db.model('User', userSchema);
const user = new User({ name: '', email: '' });
const err = await user.validate().then(() => null, err => err);

err.errors['name']; // ValidatorError
err.errors['email']; // ValidatorError
Required Validators On Nested Objects
De ning validators on nested objects in mongoose is tricky, because nested objects are not fully
edged paths.
let personSchema = new Schema({

name: {
first: String,
last: String
}
});
assert.throws(function() {
// This throws an error, because 'name' isn't a full fledged path
personSchema.path('name').required(true);
}, /Cannot.*'required'/);
// To make a nested object required, use a single nested schema

const nameSchema = new Schema({
first: String,
last: String
});
personSchema = new Schema({

name: {
type: nameSchema,
required: true
}
});
const Person = db.model('Person', personSchema);
const person = new Person();

const error = person.validateSync();
assert.ok(error.errors['name']);
Update Validators
In the above examples, you learned about document validation. Mongoose also supports
validation for update() , updateOne() , updateMany() , and findOneAndUpdate() operations.
Update validators are o by default - you need to specify the runValidators option.
To turn on update validators, set the runValidators option for update() , updateOne() ,
updateMany() , or findOneAndUpdate() . Be careful: update validators are o by default because
they have several caveats.

color: String,
name: String
});
const Toy = db.model('Toys', toySchema);
Toy.schema.path('color').validate(function(value) {
return /red|green|blue/i.test(value);
}, 'Invalid color');
const opts = { runValidators: true };
let error;
try {
await Toy.updateOne({}, { color: 'not a color' }, opts);
} catch (err) {
error = err;
}
assert.equal(error.errors.color.message, 'Invalid color');
Update Validators and this
There are a couple of key di erences between update validators and document validators. In the
color validation function below, this refers to the document being validated when using
document validation. However, when running update validators, this refers to the query object
instead of the document. Because queries have a neat .get() function, you can get the updated
value of the property you want.

color: String,
name: String
});
toySchema.path('color').validate(function(value) {
// When running in `validate()` or `validateSync()`, the
// validator can access the document using `this`.
// When running with update validators, `this` is the Query,
// **not** the document being updated!
// Queries have a `get()` method that lets you get the
// updated value.
if (this.get('name') && this.get('name').toLowerCase().indexOf('red') !== -1) {
return value === 'red';
}
return true;
});
const Toy = db.model('ActionFigure', toySchema);
const toy = new Toy({ color: 'green', name: 'Red Power Ranger' });
// Validation failed: color: Validator failed for path `color` with value `green`
let error = toy.validateSync();
assert.ok(error.errors['color']);
const update = { color: 'green', name: 'Red Power Ranger' };

error = null;
try {
await Toy.updateOne({}, update, opts);
} catch (err) {
error = err;
}
// Validation failed: color: Validator failed for path `color` with value `green`
assert.ok(error);
Update Validators Only Run On Updated Paths
The other key di erence is that update validators only run on the paths speci ed in the update.
For instance, in the below example, because 'name' is not speci ed in the update operation,
update validation will succeed.
When using update validators, required validators only fail when you try to explicitly $unset
the key.
const kittenSchema = new Schema({

name: { type: String, required: true },
age: Number
});
const Kitten = db.model('Kitten', kittenSchema);
const update = { color: 'blue' };

Kitten.updateOne({}, update, opts, function() {
// Operation succeeds despite the fact that 'name' is not specified
});
const unset = { $unset: { name: 1 } };

Kitten.updateOne({}, unset, opts, function(err) {
// Operation fails because 'name' is required
assert.ok(err);
assert.ok(err.errors['name']);
});
Update Validators Only Run For Some Operations
One nal detail worth noting: update validators only run on the following update operators:
$set
$unset
$push
$addToSet
$pull
$pullAll
For instance, the below update will succeed, regardless of the value of number , because update
validators ignore $inc .
Also, $push , $addToSet , $pull , and $pullAll validation does not run any validation on the
array itself, only individual elements of the array.
const testSchema = new Schema({

number: { type: Number, max: 0 },
arr: [{ message: { type: String, maxlength: 10 } }]
});
// Update validators won't check this, so you can still `$push` 2 elements
// onto the array, so long as they don't have a `message` that's too long.
testSchema.path('arr').validate(function(v) {
return v.length < 2;
});
const Test = db.model('Test', testSchema);
let update = { $inc: { number: 1 } };

// There will never be a validation error here

await Test.updateOne({}, update, opts);
// This will never error either even though the array will have at
// least 2 elements.
update = { $push: [{ message: 'hello' }, { message: 'world' }] };
await Test.updateOne({}, update, opts);
Next Up
Now that we've covered Validation , let's take a look at Middleware.

mongoose
Middleware
Middleware (also called pre and post hooks) are functions which are passed control during
execution of asynchronous functions. Middleware is speci ed on the schema level and is useful
for writing plugins.
Types of Middleware
Pre
Errors in Pre Hooks
Post
Asynchronous Post Hooks
De ne Middleware Before Compiling Models
Save/Validate Hooks
Naming Con icts
Notes on ndAndUpdate() and Query Middleware
Error Handling Middleware
Aggregation Hooks
Synchronous Hooks
Types of Middleware
Mongoose has 4 types of middleware: document middleware, model middleware, aggregate

middleware, and query middleware.
Document middleware is supported for the following document functions. In Mongoose, a

document is an instance of a Model class. In document middleware functions, this refers to
the document.
validate
save
remove
updateOne
deleteOne
init (note: init hooks are synchronous)
Query middleware is supported for the following Query functions. Query middleware executes
when you call exec() or then() on a Query object, or await on a Query object. In query
middleware functions, this refers to the query.
count
countDocuments
deleteMany
deleteOne
estimatedDocumentCount
nd
ndOne
ndOneAndDelete
ndOneAndRemove
ndOneAndReplace
ndOneAndUpdate
remove
replaceOne
update
updateOne
updateMany
Aggregate middleware is for MyModel.aggregate() . Aggregate middleware executes when you

call exec() on an aggregate object. In aggregate middleware, this refers to the aggregation
object.
aggregate
Model middleware is supported for the following model functions. Don't confuse model
middleware and document middleware: model middleware hooks into static functions on a
Model class, document middleware hooks into methods on a Model class. In model middleware
functions, this refers to the model.
insertMany
All middleware types support pre and post hooks. How pre and post hooks work is described in
more detail below.
Note: If you specify schema.pre('remove') , Mongoose will register this middleware for
doc.remove() by default. If you want your middleware to run on Query.remove() use
schema.pre('remove', { query: true, document: false }, fn) .
Note: Unlike schema.pre('remove') , Mongoose registers updateOne and deleteOne

middleware on Query#updateOne() and Query#deleteOne() by default. This means that both
doc.updateOne() and Model.updateOne() trigger updateOne hooks, but this refers to a
query, not a document. To register updateOne or deleteOne middleware as document
middleware, use schema.pre('updateOne', { document: true, query: false }) .
Note: The create() function res save() hooks.
Note: Query middlewares are not executed on subdocuments.
const childSchema = new mongoose.Schema({

name: String
});
const mainSchema = new mongoose.Schema({

child: [childSchema]
});
mainSchema.pre('findOneAndUpdate', function () {
console.log('Middleware on parent document'); // Will be executed
});
childSchema.pre('findOneAndUpdate', function () {
console.log('Middleware on subdocument'); // Will not be executed
});
Pre
Pre middleware functions are executed one after another, when each middleware calls next .
const schema = new Schema(..);

schema.pre('save', function(next) {
// do stuff
next();
});
In mongoose 5.x, instead of calling next() manually, you can use a function that returns a
promise. In particular, you can use async/await .
schema.pre('save', function() {
return doStuff().
then(() => doMoreStuff());
});
// Or, in Node.js >= 7.6.0:

schema.pre('save', async function() {
await doStuff();
await doMoreStuff();
});
If you use next() , the next() call does not stop the rest of the code in your middleware
function from executing. Use the early return pattern to prevent the rest of your middleware
function from running when you call next() .
const schema = new Schema(..);

if (foo()) {
console.log('calling next!');
// `return next();` will make sure the rest of this function doesn't run
/*return*/ next();
}
// Unless you comment out the `return` above, 'after next' will print
console.log('after next');
});
Use Cases
Middleware are useful for atomizing model logic. Here are some other ideas:
complex validation
removing dependent documents (removing a user removes all their blogposts)
asynchronous defaults
asynchronous tasks that a certain action triggers
Errors in Pre Hooks
If any pre hook errors out, mongoose will not execute subsequent middleware or the hooked
function. Mongoose will instead pass an error to the callback and/or reject the returned promise.
There are several ways to report an error in middleware:
const err = new Error('something went wrong');
// If you call `next()` with an argument, that argument is assumed to be
// an error.
next(err);
});
// You can also return a promise that rejects
return new Promise((resolve, reject) => {
reject(new Error('something went wrong'));
});
});
// You can also throw a synchronous error
throw new Error('something went wrong');
});
schema.pre('save', async function() {

await Promise.resolve();
// You can also throw an error in an àsync` function
throw new Error('something went wrong');
});
// later...
// Changes will not be persisted to MongoDB because a pre hook errored out
myDoc.save(function(err) {
console.log(err.message); // something went wrong
});
Calling next() multiple times is a no-op. If you call next() with an error err1 and then throw
an error err2 , mongoose will report err1 .
Post middleware
post middleware are executed after the hooked method and all of its pre middleware have
completed.
schema.post('init', function(doc) {
console.log('%s has been initialized from the db', doc._id);
});
schema.post('validate', function(doc) {
console.log('%s has been validated (but not saved yet)', doc._id);
});
schema.post('save', function(doc) {
console.log('%s has been saved', doc._id);
});
schema.post('remove', function(doc) {
console.log('%s has been removed', doc._id);
});
Asynchronous Post Hooks
If your post hook function takes at least 2 parameters, mongoose will assume the second
parameter is a next() function that you will call to trigger the next middleware in the sequence.
// Takes 2 parameters: this is an asynchronous post hook

schema.post('save', function(doc, next) {
setTimeout(function() {
console.log('post1');
// Kick off the second post hook
next();
}, 10);
});
// Will not execute until the first middleware calls `next()`

schema.post('save', function(doc, next) {
console.log('post2');
next();
});
De ne Middleware Before Compiling Models
Calling pre() or post() after compiling a model does not work in Mongoose in general. For
example, the below pre('save') middleware will not re.
const schema = new mongoose.Schema({ name: String });
// Compile a model from the schema

const User = mongoose.model('User', schema);
// Mongoose will **not** call the middleware function, because

// this middleware was defined after the model was compiled
schema.pre('save', () => console.log('Hello from pre save'));
const user = new User({ name: 'test' });

user.save();
This means that you must add all middleware and plugins before calling mongoose.model() . The
below script will print out "Hello from pre save":

// Mongoose will call this middleware function, because this script adds
// the middleware to the schema before compiling the model.
schema.pre('save', () => console.log('Hello from pre save'));
// Compile a model from the schema

const User = mongoose.model('User', schema);
const user = new User({ name: 'test' });

user.save();
As a consequence, be careful about exporting Mongoose models from the same le that you
de ne your schema. If you choose to use this pattern, you must de ne global plugins before
calling require() on your model le.
// Once you `require()` this file, you can no longer add any middleware
// to this schema.
module.exports = mongoose.model('User', schema);
Save/Validate Hooks
The save() function triggers validate() hooks, because mongoose has a built-in
pre('save') hook that calls validate() . This means that all pre('validate') and
post('validate') hooks get called before any pre('save') hooks.
schema.pre('validate', function() {
console.log('this gets printed first');
});
schema.post('validate', function() {
console.log('this gets printed second');
});
console.log('this gets printed third');
});
schema.post('save', function() {
console.log('this gets printed fourth');
});
Naming Con icts
Mongoose has both query and document hooks for remove() .
schema.pre('remove', function() { console.log('Removing!'); });
// Prints "Removing!"
doc.remove();
// Does **not** print "Removing!". Query middleware for `remove` is not

// executed by default.
Model.remove();
You can pass options to Schema.pre() and Schema.post() to switch whether Mongoose calls
your remove() hook for Document.remove() or Model.remove() . Note here that you need to
set both document and query properties in the passed object:
// Only document middleware

schema.pre('remove', { document: true, query: false }, function() {
console.log('Removing doc!');
});
// Only query middleware. This will get called when you do `Model.remove()`
// but not `doc.remove()`.
schema.pre('remove', { query: true, document: false }, function() {
console.log('Removing!');
});
Notes on ndAndUpdate() and Query Middleware
Pre and post save() hooks are not executed on update() , findOneAndUpdate() , etc. You can
see a more detailed discussion why in this GitHub issue. Mongoose 4.0 introduced distinct hooks
for these functions.
schema.pre('find', function() {
console.log(this instanceof mongoose.Query); // true
this.start = Date.now();
});
schema.post('find', function(result) {
console.log(this instanceof mongoose.Query); // true
// prints returned documents
console.log('find() returned ' + JSON.stringify(result));
// prints number of milliseconds the query took
console.log('find() took ' + (Date.now() - this.start) + ' milliseconds');
});
Query middleware di ers from document middleware in a subtle but important way: in
document middleware, this refers to the document being updated. In query middleware,
mongoose doesn't necessarily have a reference to the document being updated, so this refers
to the query object rather than the document being updated.
For instance, if you wanted to add an updatedAt timestamp to every updateOne() call, you
would use the following pre hook.
schema.pre('updateOne', function() {
this.set({ updatedAt: new Date() });
});
You cannot access the document being updated in pre('updateOne') or

pre('findOneAndUpdate') query middleware. If you need to access the document that will be
updated, you need to execute an explicit query for the document.
schema.pre('findOneAndUpdate', async function() {

const docToUpdate = await this.model.findOne(this.getQuery());
console.log(docToUpdate); // The document that `findOneAndUpdate()` will modify
});
However, if you de ne pre('updateOne') document middleware, this will be the document

being updated. That's because pre('updateOne') document middleware hooks into
Document#updateOne() rather than Query#updateOne() .
schema.pre('updateOne', { document: true, query: false }, function() {

console.log('Updating');
});

await doc.updateOne({ $set: { name: 'test' } }); // Prints "Updating"
// Doesn't print "Updating", because `Query#updateOne()` doesn't fire

// document middleware.
await Model.updateOne({}, { $set: { name: 'test' } });
Error Handling Middleware
New in 4.5.0
Middleware execution normally stops the rst time a piece of middleware calls next() with an
error. However, there is a special kind of post middleware called "error handling middleware"
that executes speci cally when an error occurs. Error handling middleware is useful for reporting
errors and making error messages more readable.
Error handling middleware is de ned as middleware that takes one extra parameter: the 'error'
that occurred as the rst parameter to the function. Error handling middleware can then
transform the error however you want.

name: {
type: String,
// Will trigger a MongoServerError with code 11000 when
// you save a duplicate
unique: true
}
});
// Handler **must** take 3 parameters: the error that occurred, the document
// in question, and the `next()` function
schema.post('save', function(error, doc, next) {
if (error.name === 'MongoServerError' && error.code === 11000) {
next(new Error('There was a duplicate key error'));
} else {
next();
}
});
// Will trigger the `post('save')` error handler

Person.create([{ name: 'Axl Rose' }, { name: 'Axl Rose' }]);
Error handling middleware also works with query middleware. You can also de ne a post
update() hook that will catch MongoDB duplicate key errors.
// The same E11000 error can occur when you call ùpdate()`
// This function **must** take 3 parameters. If you use the
// `passRawResult` function, this function **must** take 4
// parameters
schema.post('update', function(error, res, next) {
if (error.name === 'MongoServerError' && error.code === 11000) {
next(new Error('There was a duplicate key error'));
} else {
next(); // The ùpdate()` call will still error out.
}
});
const people = [{ name: 'Axl Rose' }, { name: 'Slash' }];

Person.create(people, function(error) {
Person.update({ name: 'Slash' }, { $set: { name: 'Axl Rose' } }, function(error) {
// èrror.message` will be "There was a duplicate key error"
});
});
Error handling middleware can transform an error, but it can't remove the error. Even if you call
next() with no error as shown above, the function call will still error out.
Aggregation Hooks
You can also de ne hooks for the Model.aggregate() function. In aggregation middleware
functions, this refers to the Mongoose Aggregate object. For example, suppose you're
implementing soft deletes on a Customer model by adding an isDeleted property. To make
sure aggregate() calls only look at customers that aren't soft deleted, you can use the below
middleware to add a $match stage to the beginning of each aggregation pipeline.
customerSchema.pre('aggregate', function() {
// Add a $match state to the beginning of each pipeline.
this.pipeline().unshift({ $match: { isDeleted: { $ne: true } } });
});
The Aggregate#pipeline() function lets you access the MongoDB aggregation pipeline that
Mongoose will send to the MongoDB server. It is useful for adding stages to the beginning of the
pipeline from middleware.
Synchronous Hooks
Certain Mongoose hooks are synchronous, which means they do not support functions that
return promises or receive a next() callback. Currently, only init hooks are synchronous,
because the init() function is synchronous. Below is an example of using pre and post init
hooks.
const schema = new Schema({ title: String, loadedAt: Date });
schema.pre('init', pojo => {

assert.equal(pojo.constructor.name, 'Object'); // Plain object before init
});
const now = new Date();

schema.post('init', doc => {
assert.ok(doc instanceof mongoose.Document); // Mongoose doc after init
doc.loadedAt = now;
});
return Test.create({ title: 'Casino Royale' }).

then(doc => Test.findById(doc)).
then(doc => assert.equal(doc.loadedAt.valueOf(), now.valueOf()));
To report an error in an init hook, you must throw a synchronous error. Unlike all other
middleware, init middleware does not handle promise rejections.
const schema = new Schema({ title: String });
const swallowedError = new Error('will not show');

// init hooks do **not** handle async errors or any sort of async behavior
schema.pre('init', () => Promise.reject(swallowedError));
schema.post('init', () => { throw Error('will show'); });
return Test.create({ title: 'Casino Royale' }).

then(doc => Test.findById(doc)).
catch(error => assert.equal(error.message, 'will show'));
Next Up
Now that we've covered middleware, let's take a look at Mongoose's approach to faking JOINs
with its query population helper.
mongoose
Populate
MongoDB has the join-like $lookup aggregation operator in versions >= 3.2. Mongoose has a
more powerful alternative called populate() , which lets you reference documents in other
collections.
Population is the process of automatically replacing the speci ed paths in the document with
document(s) from other collection(s). We may populate a single document, multiple documents,
a plain object, multiple plain objects, or all objects returned from a query. Let's look at some
examples.

const { Schema } = mongoose;
const personSchema = Schema({

_id: Schema.Types.ObjectId,
name: String,
age: Number,
stories: [{ type: Schema.Types.ObjectId, ref: 'Story' }]
});
const storySchema = Schema({

author: { type: Schema.Types.ObjectId, ref: 'Person' },
title: String,
fans: [{ type: Schema.Types.ObjectId, ref: 'Person' }]
});
const Story = mongoose.model('Story', storySchema);

So far we've created two Models. Our Person model has its stories eld set to an array of
ObjectId s. The ref option is what tells Mongoose which model to use during population, in
our case the Story model. All _id s we store here must be document _id s from the Story
model.
Note: ObjectId , Number , String , and Buffer are valid for use as refs. However, you should
use ObjectId unless you are an advanced user and have a good reason for doing so.
Saving Refs
Population
Checking Whether a Field is Populated
Setting Populated Fields
What If There's No Foreign Document?
Field Selection
Populating Multiple Paths
Query conditions and other options
Refs to children
Populating an existing document
Populating multiple existing documents
Populating across multiple levels
Populating across Databases
Dynamic References via `refPath`
Populate Virtuals
Populate Virtuals: The Count Option
Populate Virtuals: The Match Option
Populating Maps
Populate in Middleware
Populating Multiple Paths in Middleware
Transform populated documents
Saving refs
Saving refs to other documents works the same way you normally save properties, just assign the
_id value:
const author = new Person({

_id: new mongoose.Types.ObjectId(),
name: 'Ian Fleming',
age: 50
});
author.save(function (err) {
const story1 = new Story({

title: 'Casino Royale',
author: author._id // assign the _id from the person
});
story1.save(function (err) {
// that's it!
});
});
Population
So far we haven't done anything much di erent. We've merely created a Person and a Story .
Now let's take a look at populating our story's author using the query builder:
Story.
findOne({ title: 'Casino Royale' }).
populate('author').
exec(function (err, story) {
console.log('The author is %s', story.author.name);
// prints "The author is Ian Fleming"
});
Populated paths are no longer set to their original _id , their value is replaced with the
mongoose document returned from the database by performing a separate query before
returning the results.
Arrays of refs work the same way. Just call the populate method on the query and an array of
documents will be returned in place of the original _id s.
Setting Populated Fields
You can manually populate a property by setting it to a document. The document must be an
instance of the model your ref property refers to.
Story.findOne({ title: 'Casino Royale' }, function(error, story) {

if (error) {
return handleError(error);
}
story.author = author;
console.log(story.author.name); // prints "Ian Fleming"
});
Checking Whether a Field is Populated
You can call the populated() function to check whether a eld is populated. If populated()
returns a truthy value, you can assume the eld is populated.
story.populated('author'); // truthy
story.depopulate('author'); // Make àuthor` not populated anymore

story.populated('author'); // undefined
A common reason for checking whether a path is populated is getting the author id. However,
for your convenience, Mongoose adds a _id getter to ObjectId instances so you can use
story.author._id regardless of whether author is populated.
story.populated('author'); // truthy
story.author._id; // ObjectId
story.depopulate('author'); // Make àuthor` not populated anymore

story.populated('author'); // undefined
story.author instanceof ObjectId; // true

story.author._id; // ObjectId, because Mongoose adds a special getter
What If There's No Foreign Document?
Mongoose populate doesn't behave like conventional SQL joins. When there's no document,
story.author will be null . This is analogous to a left join in SQL.
await Person.deleteMany({ name: 'Ian Fleming' });
const story = await Story.findOne({ title: 'Casino Royale' }).populate('author');

story.author; // `null`
If you have an array of authors in your storySchema , populate() will give you an empty array
instead.
const storySchema = Schema({

authors: [{ type: Schema.Types.ObjectId, ref: 'Person' }],
title: String
});
// Later
const story = await Story.findOne({ title: 'Casino Royale' }).populate('authors');

story.authors; // `[]`
Field Selection
What if we only want a few speci c elds returned for the populated documents? This can be
accomplished by passing the usual eld name syntax as the second argument to the populate
method:
Story.
findOne({ title: /casino royale/i }).
populate('author', 'name'). // only return the Persons name
exec(function (err, story) {
console.log('The author is %s', story.author.name);

// prints "The author is Ian Fleming"
console.log('The authors age is %s', story.author.age);

// prints "The authors age is null"
});
Populating Multiple Paths
What if we wanted to populate multiple paths at the same time?
Story.
find(...).
populate('fans').
populate('author').
exec();
If you call populate() multiple times with the same path, only the last one will take e ect.
// The 2nd `populate()` call below overwrites the first because they
// both populate 'fans'.
Story.
find().
populate({ path: 'fans', select: 'name' }).
populate({ path: 'fans', select: 'email' });
// The above is equivalent to:
Story.find().populate({ path: 'fans', select: 'email' });
Query conditions and other options
What if we wanted to populate our fans array based on their age and select just their names?
Story.
find().
populate({
path: 'fans',
match: { age: { $gte: 21 } },
// Explicitly exclude `_id`, see http://bit.ly/2aEfTdB
select: 'name -_id'
}).
exec();
The match option doesn't lter out Story documents. If there are no documents that satisfy
match , you'll get a Story document with an empty fans array.
For example, suppose you populate() a story's author and the author doesn't satisfy match .
Then the story's author will be null .
const story = await Story.

findOne({ title: 'Casino Royale' }).
populate({ path: 'author', name: { $ne: 'Ian Fleming' } }).
exec();
story.author; // `null`
In general, there is no way to make populate() lter stories based on properties of the story's
author . For example, the below query won't return any results, even though author is
populated.
const story = await Story.

findOne({ 'author.name': 'Ian Fleming' }).
populate('author').
exec();
story; // null
If you want to lter stories by their author's name, you should use denormalization.
limit vs. perDocumentLimit
Populate does support a limit option, however, it currently does not limit on a per-document
basis for backwards compatibility. For example, suppose you have 2 stories:
Story.create([
{ title: 'Casino Royale', fans: [1, 2, 3, 4, 5, 6, 7, 8] },
{ title: 'Live and Let Die', fans: [9, 10] }
]);
If you were to populate() using the limit option, you would nd that the 2nd story has 0 fans:
const stories = await Story.find().populate({

path: 'fans',
options: { limit: 2 }
});
stories[0].name; // 'Casino Royale'

stories[0].fans.length; // 2
// 2nd story has 0 fans!

stories[1].name; // 'Live and Let Die'
That's because, in order to avoid executing a separate query for each document, Mongoose
instead queries for fans using numDocuments * limit as the limit. If you need the correct
limit , you should use the perDocumentLimit option (new in Mongoose 5.9.0). Just keep in
mind that populate() will execute a separate query for each story, which may cause
populate() to be slower.
const stories = await Story.find().populate({

path: 'fans',
// Special option that tells Mongoose to execute a separate query
// for each `story` to make sure we get 2 fans for each story.
perDocumentLimit: 2
});
stories[0].name; // 'Casino Royale'

stories[1].name; // 'Live and Let Die'

Refs to children
We may nd however, if we use the author object, we are unable to get a list of the stories. This
is because no story objects were ever 'pushed' onto author.stories .
There are two perspectives here. First, you may want the author to know which stories are
theirs. Usually, your schema should resolve one-to-many relationships by having a parent pointer
in the 'many' side. But, if you have a good reason to want an array of child pointers, you can
push() documents onto the array as shown below.
story1.save()
author.stories.push(story1);
author.save(callback);
This allows us to perform a find and populate combo:
Person.
findOne({ name: 'Ian Fleming' }).
populate('stories'). // only works if we pushed refs to children
exec(function (err, person) {
console.log(person);
});
It is debatable that we really want two sets of pointers as they may get out of sync. Instead we
could skip populating and directly find() the stories we are interested in.
Story.
find({ author: author._id }).
exec(function (err, stories) {
console.log('The stories are an array: ', stories);
});
The documents returned from query population become fully functional, remove able, save able
documents unless the lean option is speci ed. Do not confuse them with sub docs. Take caution
when calling its remove method because you'll be removing it from the database, not just the
array.
Populating an existing document
If you have an existing mongoose document and want to populate some of its paths, you can use
the Document#populate() method.
const person = await Person.findOne({ name: 'Ian Fleming' });
person.populated('stories'); // null
// Call the `populate()` method on a document to populate a path.

await person.populate('stories');
person.populated('stories'); // Array of ObjectIds

person.stories[0].name; // 'Casino Royale'
The Document#populate() method does not support chaining. You need to call populate()
multiple times, or with an array of paths, to populate multiple paths
await person.populate(['stories', 'fans']);

person.populated('fans'); // Array of ObjectIds
Populating multiple existing documents
If we have one or many mongoose documents or even plain objects (like mapReduce output), we
may populate them using the Model.populate() method. This is what Document#populate() and
Query#populate() use to populate documents.
Populating across multiple levels
Say you have a user schema which keeps track of the user's friends.

name: String,
friends: [{ type: ObjectId, ref: 'User' }]
});
Populate lets you get a list of a user's friends, but what if you also wanted a user's friends of
friends? Specify the populate option to tell mongoose to populate the friends array of all the
user's friends:
User.
findOne({ name: 'Val' }).
populate({
path: 'friends',
// Get friends of friends - populate the 'friends' array for every friend
populate: { path: 'friends' }
});
Cross Database Populate
Let's say you have a schema representing events, and a schema representing conversations.
Each event has a corresponding conversation thread.
const db1 = mongoose.createConnection('mongodb://127.0.0.1:27000/db1');

const db2 = mongoose.createConnection('mongodb://127.0.0.1:27001/db2');
const conversationSchema = new Schema({ numMessages: Number });

const Conversation = db2.model('Conversation', conversationSchema);
const eventSchema = new Schema({

name: String,
conversation: {
type: ObjectId,
ref: Conversation // `ref` is a **Model class**, not a string
}
});
const Event = db1.model('Event', eventSchema);
In the above example, events and conversations are stored in separate MongoDB databases.
String ref will not work in this situation, because Mongoose assumes a string ref refers to a
model name on the same connection. In the above example, the conversation model is
registered on db2 , not db1 .
// Works
const events = await Event.
find().
populate('conversation');
This is known as a "cross-database populate," because it enables you to populate across

MongoDB databases and even across MongoDB instances.
If you don't have access to the model instance when de ning your eventSchema , you can also
pass the model instance as an option to populate() .
const events = await Event.

find().
// The `model` option specifies the model to use for populating.
populate({ path: 'conversation', model: Conversation });
Dynamic References via `refPath`
Mongoose can also populate from multiple collections based on the value of a property in the
document. Let's say you're building a schema for storing comments. A user may comment on
either a blog post or a product.
const commentSchema = new Schema({

body: { type: String, required: true },
doc: {
type: Schema.Types.ObjectId,
required: true,
// Instead of a hardcoded model name in `ref`, `refPath` means Mongoose
// will look at the ònModel` property to find the right model.
refPath: 'docModel'
},
docModel: {
type: String,
required: true,
enum: ['BlogPost', 'Product']
}
});
const Product = mongoose.model('Product', new Schema({ name: String }));

const BlogPost = mongoose.model('BlogPost', new Schema({ title: String }));
const Comment = mongoose.model('Comment', commentSchema);
The refPath option is a more sophisticated alternative to ref . If ref is a string, Mongoose will
always query the same model to nd the populated subdocs. With refPath , you can con gure
what model Mongoose uses for each document.
const book = await Product.create({ name: 'The Count of Monte Cristo' });
const post = await BlogPost.create({ title: 'Top 10 French Novels' });
const commentOnBook = await Comment.create({

body: 'Great read',
doc: book._id,
docModel: 'Product'
});
const commentOnPost = await Comment.create({

body: 'Very informative',
doc: post._id,
docModel: 'BlogPost'
});
// The below `populate()` works even though one comment references the
// 'Product' collection and the other references the 'BlogPost' collection.
const comments = await Comment.find().populate('doc').sort({ body: 1 });
comments[0].doc.name; // "The Count of Monte Cristo"
comments[1].doc.title; // "Top 10 French Novels"
An alternative approach is to de ne separate blogPost and product properties on

commentSchema , and then populate() on both properties.
const commentSchema = new Schema({

body: { type: String, required: true },
product: {
required: true,
ref: 'Product'
},
blogPost: {
required: true,
ref: 'BlogPost'
}
});
// ...
// The below `populate()` is equivalent to the `refPath` approach, you

// just need to make sure you `populate()` both `product` and `blogPost`.
const comments = await Comment.find().
populate('product').
populate('blogPost').
sort({ body: 1 });
comments[0].product.name; // "The Count of Monte Cristo"
comments[1].blogPost.title; // "Top 10 French Novels"
De ning separate blogPost and product properties works for this simple example. But, if you
decide to allow users to also comment on articles or other comments, you'll need to add more
properties to your schema. You'll also need an extra populate() call for every property, unless
you use mongoose-autopopulate. Using refPath means you only need 2 schema paths and one
populate() call regardless of how many models your commentSchema can point to.
Populate Virtuals
So far you've only populated based on the _id eld. However, that's sometimes not the right
choice. For example, suppose you have 2 models: Author and BlogPost .
const AuthorSchema = new Schema({

name: String,
posts: [{ type: mongoose.Schema.Types.ObjectId, ref: 'BlogPost' }]
});
const BlogPostSchema = new Schema({

title: String,
comments: [{
author: { type: mongoose.Schema.Types.ObjectId, ref: 'Author' },
content: String
}]
});
const Author = mongoose.model('Author', AuthorSchema, 'Author');

const BlogPost = mongoose.model('BlogPost', BlogPostSchema, 'BlogPost');
The above is an example of bad schema design. Why? Suppose you have an extremely proli c
author that writes over 10k blog posts. That author document will be huge, over 12kb, and large
documents lead to performance issues on both server and client. The Principle of Least
Cardinality states that one-to-many relationships, like author to blog post, should be stored on
the "many" side. In other words, blog posts should store their author , authors should not store
all their posts .
const AuthorSchema = new Schema({

name: String
});
const BlogPostSchema = new Schema({

title: String,
comments: [{
content: String
}]
});
Unfortunately, these two schemas, as written, don't support populating an author's list of blog
posts. That's where virtual populate comes in. Virtual populate means calling populate() on a
virtual property that has a ref option as shown below.
// Specifying a virtual with a `ref` property is how you enable virtual

// population
AuthorSchema.virtual('posts', {
ref: 'BlogPost',
localField: '_id',
foreignField: 'author'
});

You can then populate() the author's posts as shown below.
const author = await Author.findOne().populate('posts');
author.posts[0].title; // Title of the first blog post
Keep in mind that virtuals are not included in toJSON() and toObject() output by default. If
you want populate virtuals to show up when using functions like Express' res.json() function
or console.log() , set the virtuals: true option on your schema's toJSON and toObject()
options.
const authorSchema = new Schema({ name: String }, {

toJSON: { virtuals: true }, // So `res.json()` and other `JSON.stringify()` functions incl
toObject: { virtuals: true } // So `console.log()` and other functions that use `toObject
});
If you're using populate projections, make sure foreignField is included in the projection.
let authors = await Author.

find({}).
// Won't work because the foreign field àuthor` is not selected
populate({ path: 'posts', select: 'title' }).
exec();
authors = await Author.

find({}).
// Works, foreign field àuthor` is selected
populate({ path: 'posts', select: 'title author' }).
exec();
Populate Virtuals: The Count Option
Populate virtuals also support counting the number of documents with matching foreignField
as opposed to the documents themselves. Set the count option on your virtual:
const PersonSchema = new Schema({

name: String,
band: String
});
const BandSchema = new Schema({

name: String
});
BandSchema.virtual('numMembers', {
ref: 'Person', // The model to use
localField: 'name', // Find people where `localField`
foreignField: 'band', // is equal to `foreignField`
count: true // And only get the number of docs
});
// Later
const doc = await Band.findOne({ name: 'Motley Crue' }).
populate('numMembers');
doc.numMembers; // 2
Populate Virtuals: The Match Option
Another option for Populate virtuals is match . This option adds an extra lter condition to the
query Mongoose uses to populate() :
// Same example as 'Populate Virtuals' section

ref: 'BlogPost',
localField: '_id',
foreignField: 'author',
match: { archived: false } // match option with basic query selector
});

// After population
const author = await Author.findOne().populate('posts');
author.posts // Array of not àrchived` posts
You can also set the match option to a function. That allows con guring the match based on the
document being populated. For example, suppose you only want to populate blog posts whose
tags contain one of the author's favoriteTags .
ref: 'BlogPost',
localField: '_id',
foreignField: 'author',
// Add an additional filter `{ tags: author.favoriteTags }` to the populate query
// Mongoose calls the `match` function with the document being populated as the
// first argument.
match: author => ({ tags: author.favoriteTags })
});
Populating Maps
Maps are a type that represents an object with arbitrary string keys. For example, in the below
schema, members is a map from strings to ObjectIds.
const BandSchema = new Schema({

name: String,
members: {
type: Map,
of: {
type: 'ObjectId',
ref: 'Person'
}
}
});
const Band = mongoose.model('Band', bandSchema);
This map has a ref , which means you can use populate() to populate all the ObjectIds in the
map. Suppose you have the below band document:
const person1 = new Person({ name: 'Vince Neil' });

const person2 = new Person({ name: 'Mick Mars' });
const band = new Band({

name: 'Motley Crue',
members: {
'singer': person1._id,
'guitarist': person2._id
}
});
You can populate() every element in the map by populating the special path members.$* . $*
is a special syntax that tells Mongoose to look at every key in the map.
const band = await Band.findOne({ name: 'Motley Crue' }).populate('members.$*');
band.members.get('singer'); // { _id: ..., name: 'Vince Neil' }
You can also populate paths in maps of subdocuments using $* . For example, suppose you
have the below librarySchema :
const librarySchema = new Schema({

name: String,
books: {
type: Map,
of: new Schema({
title: String,
author: {
type: 'ObjectId',
ref: 'Person'
}
})
}
});
const Library = mongoose.model('Library', librarySchema);
You can populate() every book's author by populating books.$*.author :
const libraries = await Library.find().populate('books.$*.author');
Populate in Middleware
You can populate in either pre or post hooks. If you want to always populate a certain eld, check
out the mongoose-autopopulate plugin.
// Always attach `populate()` to `find()` calls

MySchema.pre('find', function() {
this.populate('user');
});
// Always `populate()` after `find()` calls. Useful if you want to selectively populate
// based on the docs found.
MySchema.post('find', async function(docs) {
for (let doc of docs) {
if (doc.isPublic) {
await doc.populate('user');
}
}
});
// `populate()` after saving. Useful for sending populated data back to the client in an
// update API endpoint
MySchema.post('save', function(doc, next) {
doc.populate('user').then(function() {
next();
});
});
Populating Multiple Paths in Middleware
Populating multiple paths in middleware can be helpful when you always want to populate some
elds. But, the implementation is just a tiny bit trickier than what you may think. Here's how you
may expect it to work:

email: String,
password: String,
followers: [{ type: mongoose.Schema.Types.ObjectId, ref: 'User' }],
following: [{ type: mongoose.Schema.Types.ObjectId, ref: 'User' }]
})
userSchema.pre('find', function (next) {

this.populate("followers following");
next();
});
const User = mongoose.model('User', userSchema)
However, this will not work. By default, passing multiple paths to populate() in the middleware
will trigger an in nite recursion, which means that it will basically trigger the same middleware
for all of the paths provided to the populate() method - For example,
this.populate('followers following') will trigger the same middleware for both followers
and following elds and the request will just be left hanging in an in nite loop.
To avoid this, we have to add the _recursed option, so that our middleware will avoid
populating recursively. The example below will make it work as expected.
userSchema.pre('find', function (next) {

if (this.options._recursed) {
return next();
}
this.populate({ path: "followers following", options: { _recursed: true } });
next();
});
Alternatively, you can check out the mongoose-autopopulate plugin.
Transform populated documents
You can manipulate populated documents using the transform option. If you specify a
transform function, Mongoose will call this function on every populated document in the result
wiwith two arguments: the populated document, and the original id used to populate the
document. This gives you more control over the result of the populate() execution. It is
especially useful when you're populating multiple documents.
The original motivation for the transform option was to give the ability to leave the unpopulated
_id if no document was found, instead of setting the value to null :
// With `transform`
doc = await Parent.findById(doc).populate([
{
path: 'child',
// If `doc` is null, use the original id instead
transform: (doc, id) => doc == null ? id : doc
}
]);
doc.child; // 634d1a5744efe65ae09142f9
doc.children; // [ 634d1a67ac15090a0ca6c0ea, { _id: 634d1a4ddb804d17d95d1c7f, name: 'Luke',
You can return any value from transform() . For example, you can use transform() to " atten"
populated documents as follows.
let doc = await Parent.create({ children: [ { name: 'Luke' }, { name: 'Leia' } ] });
doc = await Parent.findById(doc).populate([{

path: 'children',
transform: doc => doc == null ? null : doc.name
}]);
doc.children; // ['Luke', 'Leia']
Another use case for transform() is setting $locals values on populated documents to pass
parameters to getters and virtuals. For example, suppose you want to set a language code on
your document for internationalization purposes as follows.
const internationalizedStringSchema = new Schema({

en: String,
es: String
});
const ingredientSchema = new Schema({

// Instead of setting `name` to just a string, set `name` to a map
// of language codes to strings.
name: {
type: internationalizedStringSchema,
// When you access `name`, pull the document's locale
get: function(value) {
return value[this.$locals.language || 'en'];
}
}
});
const recipeSchema = new Schema({

ingredients: [{ type: mongoose.ObjectId, ref: 'Ingredient' }]
});
const Ingredient = mongoose.model('Ingredient', ingredientSchema);

const Recipe = mongoose.model('Recipe', recipeSchema);
You can set the language code on all populated exercises as follows:
// Create some sample data

const { _id } = await Ingredient.create({
name: {
en: 'Eggs',
es: 'Huevos'
}
});
await Recipe.create({ ingredients: [_id] });
// Populate with setting `$locals.language` for internationalization

const language = 'es';
const recipes = await Recipe.find().populate({
path: 'ingredients',
transform: function(doc) {
doc.$locals.language = language;
return doc;
}
});
// Gets the ingredient's name in Spanish `name.es`

recipes[0].ingredients[0].name; // 'Huevos'

Mongoose: Schemas

Uploaded by

Copyright:

Available Formats

Mongoose: Schemas

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mongoose: Schemas

Uploaded by

Copyright:

Available Formats

mongoose

De ning your schema

De ning your schema

import mongoose from 'mongoose';

const blogSchema = new Schema({

The permitted SchemaTypes are:

Read more about SchemaTypes here.

const Blog = mongoose.model('Blog', blogSchema);

By default, Mongoose adds an _id property to your schemas.

const schema = new Schema();

schema.path('_id'); // ObjectId { ... }

const Model = mongoose.model('Test', schema);

const doc = new Model();

const schema = new Schema({ _id: Number });

const doc = new Model();

// Or, assign a function to the "methods" object of our animalSchema

const Animal = mongoose.model('Animal', animalSchema);

dog.findSimilarTypes((err, dogs) => {

Add a function property to the second argument of the schema-constructor ( statics )

// Or, Assign a function to the "statics" object of our animalSchema

const Animal = mongoose.model('Animal', animalSchema);

// Or, Assign a function to the "query" object of our animalSchema

const Animal = mongoose.model('Animal', animalSchema);

Animal.find().byName('fido').exec((err, animals) => {

Animal.findOne().byName('fido').exec((err, animal) => {

const animalSchema = new Schema({

animalSchema.index({ name: 1, type: -1 }); // schema level

See SchemaType#index() for other index options.

mongoose.connect('mongodb://user:[email protected]:port/database', { autoIndex: false });

Animal.on('index', error => {

See also the Model#ensureIndexes method.

// compile our model

console.log(axl.name.first + ' ' + axl.name.last); // Axl Rose

// That can be done either by adding it to schema options:

// Or by using the virtual method as following:

console.log(axl.fullName); // Axl Rose

// Again that can be done either by adding it to schema options:

// Or by using the virtual method as following:

axl.fullName = 'William Rose'; // Now `axl.name.first` is "William"

You can learn more about virtuals here.

const personSchema = new Schema({

// Setting `name` will propagate to `n`

person.name = 'Not Val';

const childSchema = new Schema({

const parentSchema = new Schema({

new Schema({..}, options);

const schema = new Schema({..});

const schema = new Schema({..}, { autoIndex: false });

Before Mongoose builds indexes, it calls Model.createCollection() to create the underlying

You can disable this behavior by setting autoCreate to false using

Unfortunately, createCollection() cannot change an existing collection. For example, if you

const schema = new Schema({ name: String }, {

// No-op if collection already exists, even if the collection is not capped.

const schema = new Schema({..}, { bufferCommands: false });

The schema bufferCommands option overrides the global bufferCommands option.

// If an operation is buffered for more than 1 second, throw an error.

Mongoose supports MongoDBs capped collections. To specify the underlying MongoDB

new Schema({..}, { capped: 1024 });

// Because `selectPopulatedPaths` is false, the below doc will not