Contraintes de type, d’obligation et d’énumération

MongoDB JSON Schema validators support three fundamental constraint categories that cover the majority of real-world validation needs: type constraints that enforce the BSON data type of a field, required constraints that mandate the presence of certain fields, and enum constraints that restrict a field's value to a predefined whitelist. Together they form the backbone of any production schema validator.

JSON Schema uses standard JSON types like string, number, and object. MongoDB extends this with BSON types declared via the bsonType keyword—values like objectId, date, int, long, double, and decimal. Always use bsonType in MongoDB validators (not type) when you need precision about numeric subtypes or MongoDB-specific types like objectId and date.

The required keyword takes an array of field names that must be present in every document inserted or updated in the collection. If any required field is missing, the write is rejected. Required fields are declared at the schema level, not inside individual property definitions.

The enum keyword restricts a field to a fixed list of permitted values. This is ideal for status fields, category codes, or any field that must come from a controlled vocabulary. Attempting to insert a value outside the enum list causes the write to fail with a validation error.

For numeric fields, JSON Schema provides minimum, maximum, exclusiveMinimum, and exclusiveMaximum keywords. These work alongside bsonType to enforce valid ranges—for example, ensuring a product price is positive and a rating falls between 1 and 5.

String fields support minLength and maxLength to enforce character count limits. A username might need to be at least 3 characters and at most 30. A description field might have a 2000-character cap. These constraints prevent accidentally storing empty strings or truncated text that exceeds UI display limits.

The pattern keyword accepts a regular expression string and validates that the field value matches it. This is useful for enforcing email format, phone number patterns, UUID format, or slug conventions. Unlike regex queries used for search, pattern constraints run at write time to block non-conforming data from entering the collection.

Type and enum can be combined. Providing both bsonType and enum ensures the value is both of the correct type and within the allowed set. Without bsonType, an enum will accept any type that matches—including a number equal to the string value if JavaScript coercion were involved. Explicit types make validation intent clear.

By default, MongoDB validators allow any extra fields not mentioned in properties. Setting additionalProperties: false prevents documents from containing fields not declared in the schema. This is a strict mode that can catch typos in field names during development, though it can be too rigid for schemas that evolve frequently.

The description keyword inside each property definition is included in the validation error message returned to the client. Writing clear, human-readable descriptions like 'Email must be a valid address' or 'Rating must be between 1 and 5' makes it much easier for developers and API consumers to understand and fix validation failures without reading the schema.

After adding a validator, always test it with both valid and invalid documents to confirm it behaves as expected. Try inserting a document missing a required field, a field with the wrong type, and a field with a value outside the enum. Also insert a perfectly valid document to confirm it is accepted. This two-sided testing prevents overly strict validators that block legitimate writes.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: bsonType enforces BSON-specific data types including objectId and date, required declares mandatory fields at the schema level, and enum restricts a field to a fixed list of allowed values. Next up we explore validation levels and actions to control how strictly MongoDB enforces these rules.