Everyone knows that MongoDB is schemaless, then why it is required to perform schema validation? It is easy and fast to develop the application with MongoDB’s schema-less behavior and use it as a proof of concept. But once the application moves to production and becomes stable and mature, there is no need to change the schema frequently and it is not advisable also. At this time, it is very important to enforce some schema validation in your database to avoid unwanted data being inserted which can break your application. This becomes much more important when data is being inserted from multiple sources in the same database. Schema validation allows you to define the specific structure of documents in each collection. If anyone tries to insert some documents which don’t match with the defined schema, MongoDB can reject this kind of operation or give warnings according to the type of validation action. MongoDB provides two ways to validate your schema, Document validation, and JSON schema validation. JSON Schema validation is the extended version of document validation, so let’s start with document validation. Document ValidationMost of the developers who have worked with relational databases know the importance of predictability of the data models or schema. Therefore, MongoDB introduced document validation from version 3.2. Let’s see how to add validation rules in MongoDB collections. Suppose, you have a collection of users which have the following types of documents.
And, following are the validations which we want to check while adding new documents in users collection:
To add this validation, we can use the “validator” construct while creating a new collection. Run the following query in Mongo shell,
You should see the following output:
Now, if you try to add any new document without following the validation rules then mongo will throw a validation error. Try to run the following insert queries. Query:1
Output:
Query:2
Output:
However, there are some restrictions with document validation approach such as one can add any number of new key-value pair to the document and insert it into the collection. This can’t be prevented by document validation. Consider the following example,
Output:
Apart from this, document validation only checks for the values. Suppose, if you try to add the document with “nmae”(typo) as a key instead of “name”, mongo will consider it as a new field and the document will be inserted in the DB. These things should be avoided when you are working with the production database. To support all this, MongoDB introduced the “jsonSchema” operator with “validator” construct from version 3.6. Let’s see how to add the same validation rules as above and avoid adding new/misspelled fields. Severalnines
Become a MongoDB DBA – Bringing MongoDB to Production Learn about what you need to know to deploy, monitor, manage and scale MongoDB Download for Free jsonSchema ValidationRun the following command in mongo shell to add the validation rules using “jsonSchema” operator.
Let’s see now, what happens when we try to insert the following document.
It will throw an error as we haven’t defined gender field in the “jsonSchema”.
Same way, if you have typos in any field names, mongo will throw the same error. The schema defined above is the same as the one which we used in document validation. Additionally, we added the “additionalProperties” field to avoid typos in field names and the addition of new fields in documents. It will allow only fields that are defined under “properties” field. Here is the overview of some properties which we can use under “jsonSchema” operator.
Apart from schema validation, “jsonSchema” operator can also be used in find and match stage inside the aggregation pipeline. ConclusionDocument/Schema validations are not required or desirable in all situations but generally, it’s a good practice to add them in your database as it will increase the productivity of developers who are dealing with your database. They will know what kind of response to expect from the database since there won’t be any random data. |