The previous blog discussed MongoDB’s $jsonschema behavior with a strict validation level. Let’s look at the moderate validation level in this blog.
Example
As usual, first, let’s create a collection and add a few JSON documents to it. Afterwards a schema validation is added with the moderate setting (the following is based on MongoDB version 3.6.1).
> mongo
> use moderate_exploration
Initially, before adding a schema, two JSON objects are inserted that are not compliant with the schema that is going to be added afterwards. The reason is that we need non-compliant JSON objects to discuss the moderate level later.
> db.orders.insert({
"orderId": 1,
"orderDate": ISODate("2017-09-30T00:00:00Z"),
"orderLineItems": [{
"itemId": 55,
"numberOrdered": 20
}, {
"itemId": 56,
"numberOrdered": 21
}],
"specialInstructions": "Drop of in front,
not back of location"
})
WriteResult({ "nInserted" : 1 })
> db.orders.insert({
"orderId": 2,
"orderDate": ISODate("2017-09-30T00:00:00Z"),
"orderLineItems": [{
"itemId": 55,
"numberOrdered": 40
}, {
"itemId": 56,
"numberOrdered": 41
}],
"preferredColor": "red"
})
WriteResult({ "nInserted" : 1 })
Now the schema is added:
> db.runCommand({
"collMod": "orders",
"validator": {
"$jsonSchema": {
"bsonType": "object",
"required": ["orderId", "orderDate", "orderLineItems"],
"properties": {
"orderId": {
"bsonType": "int",
"description": "Order Identifier: must be of
type int and is required"
},
"orderDate": {
"bsonType": "date",
"description": "Order Date: must be of
type date and is required"
},
"orderLineItems": {
"bsonType": "array",
"items": {
"bsonType": "object",
"properties": {
"itemId": {
"bsonType": "int"
},
"numberOrdered": {
"bsonType": "int"
}
}
},
"description": "Order Line Items: must be of
type array and is required"
}
}
}
},
"validationLevel": "moderate",
"validationAction": "error"
})
{ "ok" : 1 }
After the schema is added, two more JSON objects are inserted, this time being schema compliant.
> db.orders.insert({
"orderId": NumberInt(3),
"orderDate": ISODate("2017-09-30T00:00:00Z"),
"orderLineItems": [{
"itemId": NumberInt(55),
"numberOrdered": NumberInt(60)
}, {
"itemId": NumberInt(56),
"numberOrdered": NumberInt(61)
}]
})
WriteResult({ "nInserted" : 1 })
> db.orders.insert({
"orderId": NumberInt(4),
"orderDate": ISODate("2017-09-30T00:00:00Z"),
"orderLineItems": [{
"itemId": NumberInt(55),
"numberOrdered": NumberInt(80)
}, {
"itemId": NumberInt(56),
"numberOrdered": NumberInt(81)
}]
})
WriteResult({ "nInserted" : 1 })
At this point the created collection is governed by a schema, and contains four JSON documents, two are compliant with the schema (orderId 3 and 4), and two are not compliant (orderId 1 and 2).
Analysis
The MongoDB documentation states for “moderate”: “Apply validation rules to inserts and to updates on existing valid documents. Do not apply rules to updates on existing invalid documents.” (https://docs.mongodb.com/manual/reference/command/collMod/#validationLevel).
Let’s explore now the behavior of the moderate validation level.
First, let’s try to insert a non-compliant JSON document. The insert will fail as expected:
> db.orders.insert({
"orderId": 5,
"orderDate": ISODate("2017-09-30T00:00:00Z"),
"orderLineItems": [{
"itemId": 55,
"numberOrdered": 40
}, {
"itemId": 56,
"numberOrdered": 41
}],
"preferredColor": "red"
})
WriteResult({
"nInserted": 0,
"writeError": {
"code": 121,
"errmsg": "Document failed validation"
}
})
Second, let’s try to update a compliant JSON document that already exists in the collection in a non-compliant way:
> db.orders.update({
"orderId": NumberInt(3)
}, {
"$set": {
"orderDate": "2018-01-09"
}
})
As expected the update fails:
WriteResult({
"nMatched" : 0,
"nUpserted" : 0,
"nModified" : 0,
"writeError" : {
"code" : 121,
"errmsg" : "Document failed validation"
}
})
Third, let’s try to update a non-compliant JSON document
> db.orders.update({
"orderId": NumberInt(1)
}, {
"$set": {
"orderDate": "2018-01-10"
}
})
As per the above explanation of moderate this should work and indeed it does:
WriteResult({
"nMatched": 1,
"nUpserted": 0,
"nModified": 1
})
Bypassing Validation
With the correct permission (https://docs.mongodb.com/manual/reference/privilege-actions/#bypassDocumentValidation) it is possible to bypass document validation.
This allows for the situation that e.g. a collection is governed by a new schema, however, existing application code might have to continue to insert or to update documents with a structure that violates the new schema as the logic cannot be adjusted to the new schema quickly enough (including transforming the non-compliant to compliant JSON documents).
Summary
The brief analysis of MongoDB wrt. document validation in context of JSON schemas added to collections in the last three blogs showed that while schema supervision is possible, it is not as strict as in relational database management systems.
Basically, if a schema is present, a user cannot infer that all documents in that collection comply to that schema. A schema related to a collection can be changed, and existing documents that would violate the new schema on insert will not be discarded from the collection. Furthermore, properties that are not covered by the schema can be added and changed freely.
Go [ JSON | Relational ] SQL!
Disclaimer
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
r e a l - p r o g r a m m e r 