Movatterモバイル変換


[0]ホーム

URL:


Skip to content
DEV Community
Log in Create account

DEV Community

Leandro Domingues
Leandro Domingues

Posted on

     

MongoDB Schema Validation

E aí pessoal, tudo certo? Hoje aqui em Porto Alegre, depois de mais uma semana treinando em MongoDB uma turma de devs. E como um dos assuntos foi a validação de documentos, compartilho com vocês uma visão desse recurso que vem se tornando cada dia mais importante.

Porque validar?

Bom, confesso que a primeira vez que tive notícias sobre o schema validation pensei: meu, pra que delegar isso pra um banco que tem como sua principal característica a performance?

Sim, porque quando pensamos em bancos NoSQL o primeiro que nos vem à cabeça é: vou gravar qualquer coisa, que legal! E realmente na maioria dos projetos iniciados com NoSQL é isso que acontece, porém, a medida em que as aplicações vão crescendo e aumentando o volume dos dados e de acesso, um mínimo de organização é requerido. É aí que entra o Schema Validation!

Validação no MongoDB, isso é novo?

Não. A validação de documentos foi introduzida originalmente na versão 3.2 e evoluiu muito desde então. O que começou timidamente com suporte a alguns poucos operadores, hoje tem um operador exclusivo e bastante robusto!

Agora com a versão 3.6 temos o $jsonSchema que está baseado no draft 4 doJSON Schema.

Quando especificada, a validação ocorrerá a cada insert ou update na coleção criada utilizando a opçãovalidator, que por sua vez terá as regras ou expressões de validação.

Assim como todas as funções que possam afetar a performance do banco, o schema validation pode ser ligado ou desligado a qualquer momento e tem alguns comportamentos para esses casos.

Validation Level e Validation Action

Podemos utilizar o schema validation para uma coleção que já exista e contenha documentos utilizando o comandocollMod, como também podemos especificar no momento da criação de uma nova especificando as regras através do opçãovalidator no comandodb.createCollection().

OvalidationLevel determina como o MongoDB aplica as regras de validação para documentos existentes durante um update. Já a opçãovalidationAction determina se o MongoDB retornará umerro e rejeita os documentos que estão violando as regras de validação ou gravará umwarn com essas violações no log e permitirá esses documentos inválidos.

Documentos Existentes

Podemos controlar como o MongoDB gerencia os documentos existentes utilizando a opçãovalidationLevel.

Por default, ovalidationLevel éstrict e o MongoDB aplicará as regras de validação em todos os inserts e updates. Setando ovalidationLevel paramoderate fará com que as regras sejam aplicadas para os inserts e updates e nos documentos existentes que preencham todos os requisitos da validação. Os documentos existentes na coleção e que não atendam essas regras não serão verificados.

Aplicando uma validação simples

Nesse exemplo vou criar uma coleção chamada clientes onde vou requerer os campos documento, nome e cep. Vejamos como fica:

db.createCollection("clientes",{validator:{$jsonSchema:{bsonType:"object",required:["documento","nome","endereco.cep"],properties:{"documento":{bsonType:"string",description:"O Documento é um atributo requerido e contém o CPF do cliente",maxLength:11,minLength:11,},"nome":{bsonType:"string",description:"O Nome é um atributo requerido"},"endereco.cep":{bsonType:"string",description:"O CEP é um atributo requerido",maxLength:8,minLength:8}}}}});

Vejamos mais detalhadamente cada uma das opções que especifiquei novalidator:

$jsonSchema

Esse é o objeto principal para utilizarmos o schema validation e termos acesso a mais recursos. Dentro dele especificamos o tipoobject para obsonType, em seguida declaramos umarray que deverá conter os nomes dos atributos requeridos no documento.

properties

Nesse nível definimos as propriedades da validação para cada atributo, ou melhor, entramos mais a fundo atributo por atributo e vamos além da simples obrigatoriedade do atributo.

Note que para cada atributo colocamos propriedades diferentes, podemos definir obsonType, dar uma descrição e até definir tamanho mínimo e máximo.

Váriaskey-words são permitidas nas propriedades e nos permitem uma gama gigantesca de combinações para as validações. Veja mais detalhes dessaskey-words aqui

Esses são os atributos mínimos para habilitar a validação em uma coleção.

Aceitando ou Rejeitando Documentos Inválidos

Como disse quem controla esse processo de "ok" ou "não ok" na validação é ovalidationAction.

Tendo por base o schema definido em nosso exemplo, com ovalidationAction setado paraerror, todos os documentos que não estiverem dentro das regras serão rejeitados e o MongoDB retornará uma mensagem de erro.

Já para aactionwarn o documento será aceito (inserido ou atualizado), porém, um registro no log será gerado, vejamos um exemplo:

db.clientes.insert({nome:"Leandro",status:"Atualizado"})
2017-12-01T12:31:23.738-0500 W STORAGE[conn1] Document would fail validation collection: testeSchema.clientes doc:{ _id: ObjectId('5a2191ebacbbfc2bdc4dcffc'), nome:"Leandro", status:"Atualizado"}

Restrições e Bypass

Não conseguimos especificar uma validação para as coleções dos bancosadmin,local,config. Tampouco para as coleçõessystem.*

Algumasroles podem têm permissão para dar umbypass no schema validation, são elas:dbAdmin erestore. Em um ambiente com autenticação habilitada umbypass na validação tem que usar a opçãobypassDocumentValidation, mas um conselho: não fale dessa opção pra muita gente! Rssss

Conclusão

Bem pessoal, é isso... espero ter ajudado vocês a conhecerem um pouco mais sobre esse recurso que à medida em que nossos dados crescem se faz cada vez mais necessário. Para mais informações acesse a página com a documentação oficial do MongoDBaqui

Até a próxima...

PS: comecei a escrever em Porto Alegre e terminei no Rio de Janeiro! ;)

Top comments(0)

Subscribe
pic
Create template

Templates let you quickly answer FAQs or store snippets for re-use.

Dismiss

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment'spermalink.

For further actions, you may consider blocking this person and/orreporting abuse

Head of NoSQL at Extractta, MongoDB Champion, Neo4J Certified, Community Manager, Speaker, Former from UNICAMP
  • Work
    Head of NoSQL at Power Tuning
  • Joined

More fromLeandro Domingues

DEV Community

We're a place where coders share, stay up-to-date and grow their careers.

Log in Create account

[8]ページ先頭

©2009-2025 Movatter.jp