Configura validadores de colección con JSON Schema y expresiones para controlar tipos, campos requeridos y evolución gradual sin depender solo de la aplicación.
Schema validation permite que MongoDB Server rechace o advierta escrituras que no cumplen una estructura definida. La validación vive en la colección y protege los datos aunque la operación provenga de otro servicio, un script, o una herramienta que no utiliza Mongoose.
mongosh
MongoDB permite construir validators con:
$jsonSchema para tipos, campos y estructuras;
query expressions para condiciones adicionales;
combinaciones de ambas cuando el contrato lo requiere.
La validación de base no reemplaza la validación de entrada ni las reglas de negocio. Cada capa protege una frontera diferente.
Este validator comprueba forma y tipos. No verifica que productId exista, que el total sea igual a la suma de items ni que el usuario tenga acceso al negocio.
Si el schema admite campos adicionales, debe decidirse conscientemente. Restringir demasiado puede dificultar evolución; permitir todo puede esconder errores tipográficos.
Aun así, un maxItems alto no protege por sí solo tamaño del documento, frecuencia de actualización o hotspot. Validation protege el contrato, no el rendimiento completo.
Las expresiones complejas pueden volver el validator difícil de mantener y costoso. Reglas que dependen de otras colecciones o del usuario pertenecen normalmente al caso de uso.
Ayuda durante migraciones porque permite tratar de forma diferente documentos antiguos que ya eran inválidos. Debe verificarse la semántica exacta de la versión utilizada antes de depender de ella.
moderate no es una solución permanente para ignorar documentos incorrectos. Debe acompañarse de backfill, métricas y una fecha para endurecer validation.
Añadir un validator no reescribe automáticamente documentos existentes. La colección puede seguir conteniendo datos antiguos que no cumplen el nuevo contrato.
Por eso deben existir dos verificaciones:
validación de escrituras futuras;
auditoría y migración de datos existentes.
Una aggregation con $type puede ayudar a inspeccionar:
Los procesos de carga deben respetar o gestionar validation deliberadamente. Desactivarla temporalmente aumenta riesgo y requiere verificación posterior.
Schema validation protege el contrato BSON persistido, pero no sustituye autorización, reglas de negocio ni migraciones. Su valor aparece cuando forma parte de una defensa en profundidad y se despliega de manera compatible con los datos existentes.
Comprueba lo aprendido
¿Qué protege un validator que TypeScript no puede proteger?
¿Por qué required no modela por sí solo campos condicionales?
¿Cómo añadirías un campo requerido a una colección con millones de documentos antiguos?
¿Qué diferencia práctica existe entre warn y error?
¿Por qué un validator no garantiza que una referencia exista?
¿Qué reglas evitarías colocar dentro de database validation?