Chapter 10. Complex Schemas

In this chapter, we will explore the ways in which Mongoose can help you manage more complex data models. MongoDB is not a relational database, so there are no SQL-style JOIN commands. Instead, we will introduce the concepts of population and subdocuments, exploring how they are used.

By the end of this chapter, you will understand the differences between the two, and when each type is appropriate. We will also have added examples to our MongoosePM application.

Population – references to other collections

MongoDB and Mongoose do not support JOIN commands as MongoDB is not a relational database. Mongoose gives you an elegant way to achieve similar functionality by using population.

Note

The concept of Population was dramatically expanded upon in Version 3.6 of Mongoose. Older versions won't support everything referenced in this chapter.

Population works by pulling information into the model you're currently using from a second model. Unlike JOIN statements, these are actually separate queries. First you retrieve your primary set of data from a collection, and once that is returned, you "populate" the required data from a secondary collection. We'll see this in some code very soon.

Defining data for population

The first step to setting up population is in the schema. Your primary schema links to the referenced model by passing an object containing the name of the model to be used and the SchemaType of the linked schema object.

In our application, there...

Subdocuments

Subdocuments are very similar to the ordinary documents we have been using so far. They are individual documents with their own schema. The big difference is that subdocuments are documents that are stored within a parent document, instead of a MongoDB collection of their own.

Perhaps an example will demonstrate this best. In our MongoosePM application, tasks are currently lacking in functionality as tasks for a given project is just a string. It would be better if a task had a distinct schema like the following:

var taskSchema = new mongoose.Schema({
  taskName: { type: String, required: true, validate: validateLength },
  taskDesc: String,
  createdOn: { type: Date, default: Date.now },
  createdBy: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true},
  modifiedOn: Date,
  assignedTo: { type: mongoose.Schema.Types.ObjectId, ref: 'User' }
});

This schema looks a bit more useful right? In a relational database this would be a standalone table, and you would run...

Data management when modifying existing schemas

If you have taken all of the changes outlined in this chapter and added them to your application, you'll probably notice quite early that the list of projects on the user page doesn't display. This is because we have changed the schemaType of createdBy in projectSchema from String to ObjectId. If you create new projects now, they will show up in the list.

In a development environment and a prototyping scenario, like we have here, this isn't a major issue as we can just add in some more temporary test data. If you're dealing with a live environment or pre-existing data that you want to use then you have to be a bit more careful when changing a schema in this way.

There are various ways you can handle this, both on the schema side and the data management side. A possible approach is to duplicate the existing schema in its entirety and changing the SchemaTypes that you need to.

To manage the data migration you could then either create a script to...

Summary

In this chapter, we've seen how Mongoose helps us to create and use more complex database structures. We can use nested schemas and subdocuments and also pull data from other collections. Our code examples can be used as the basis for updating our MongoosePM application with better task information and returning user details with projects. Download the code for this chapter from Packt Publishing's website to see it in greater detail.

Coming up next in the final chapter, we're going to look at how to re-use code using Mongoose plugins.