Close Menu
Código Simples .NETCódigo Simples .NET
    Facebook X (Twitter) Instagram
    Trending
    • NewSQL em 2025: O Estado Atual, Tendências e o Futuro dos Bancos de Dados Relacionais Escaláveis
    • 12 Regras Essenciais para Reduzir a Latência de Aplicações
    • Cache Hit Ratio: Como uma Simples Métrica Pode Revolucionar sua Arquitetura
    • Como a Uber calcula o tempo estimado de chegada
    • 30 APIs Gratuitas para desenvolvedores
    • Por que escalar escrita é tão mais difícil do que escalar leitura?
    • MongoDB Analyzer para .NET: Visualize e otimize suas consultas de forma simples
    • Cardinalidade: O Conceito que Transforma o Desempenho de Bancos de Dados SQL e NoSQL
    Facebook X (Twitter) Instagram
    Código Simples .NETCódigo Simples .NET
    Código Simples .NETCódigo Simples .NET
    Home»Banco de dados»NoSql»MongoDB Schema Validation

    MongoDB Schema Validation

    Leandro DominguesBy Leandro Domingues14 de maio de 20184 Mins Read NoSql
    Share
    Facebook Twitter LinkedIn WhatsApp Copy Link

    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 do JSON Schema.

    Quando especificada, a validação ocorrerá a cada insert ou update na coleção criada utilizando a opção validator, 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 comando collMod, como também podemos especificar no momento da criação de uma nova especificando as regras através do opção validator no comando db.createCollection().

    O validationLevel determina como o MongoDB aplica as regras de validação para documentos existentes durante um update. Já a opção validationAction determina se o MongoDB retornará um erro e rejeita os documentos que estão violando as regras de validação ou gravará um warn 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ção validationLevel.

    Por default, o validationLevel é strict e o MongoDB aplicará as regras de validação em todos os inserts e updates. Setando o validationLevel para moderate 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 no validator:

    $jsonSchema

    Esse é o objeto principal para utilizarmos o schema validation e termos acesso a mais recursos. Dentro dele especificamos o tipo object para o bsonType, em seguida declaramos um array 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 o bsonType, dar uma descrição e até definir tamanho mínimo e máximo.

    Várias key-words são permitidas nas propriedades e nos permitem uma gama gigantesca de combinações para as validações. Veja mais detalhes dessas key-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 é o validationAction.

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

    Já para a action warn 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 bancos admin, local, config. Tampouco para as coleções system.*

    Algumas roles podem têm permissão para dar um bypass no schema validation, são elas: dbAdmin e restore. Em um ambiente com autenticação habilitada um bypass na validação tem que usar a opção bypassDocumentValidation, 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 MongoDB aqui

    Até a próxima…

    Share. Facebook Twitter LinkedIn Telegram WhatsApp Copy Link
    Leandro Domingues
    • Website
    • X (Twitter)
    • LinkedIn

    Formado em Engenharia da Computação, entusiasta de tecnologias open-source, bigdata e NoSQL. MongoDB Ambassador / Evangelist, Top 50 Certificado em Neo4j, utiliza MongoDB e SQL Server criando aplicações em NodeJS há 3 anos. CTO / Co-owner da Cluster Consultoria, uma empresa especializada em bancos de dados NoSQL

    Posts Relacionados

    MongoDB Analyzer para .NET: Visualize e otimize suas consultas de forma simples

    NoSql 7 de fevereiro de 20255 Mins Read

    Cardinalidade: O Conceito que Transforma o Desempenho de Bancos de Dados SQL e NoSQL

    NoSql Sql 14 de janeiro de 20257 Mins Read

    Entendendo os diferentes tipos de locks em bancos de dados e como evitá-los

    NoSql Sql 2 de julho de 20248 Mins Read
    Newsletter

    Digite seu endereço de e-mail para receber notificações de novas publicações por e-mail.

    Junte-se a 25mil outros assinantes
    Posts recentes
    • NewSQL em 2025: O Estado Atual, Tendências e o Futuro dos Bancos de Dados Relacionais Escaláveis
    • 12 Regras Essenciais para Reduzir a Latência de Aplicações
    • Cache Hit Ratio: Como uma Simples Métrica Pode Revolucionar sua Arquitetura
    • Como a Uber calcula o tempo estimado de chegada
    • 30 APIs Gratuitas para desenvolvedores
    Categorias
    • Arquitetura (14)
      • Testes (2)
    • Asp.net (120)
      • C# (89)
      • Mvc (13)
    • Banco de dados (90)
      • NoSql (58)
      • Sql (38)
    • Boas práticas (29)
      • Gestão & Produtividade (1)
      • Metodologias Ágeis (6)
    • Cursos (52)
    • Dicas (105)
    • Front-End (92)
    • IA (1)
    • Linux (6)
    • NodeJS (4)
    • Post do Leitor (9)
    • Python (5)
    • Seo (12)
    • Tecnologia (30)
      • ITIL (1)
      • Padrões de Projeto (4)
    • Testes (2)

    VEJA TAMBÉM

    Cursos
    12 de fevereiro de 20166 Mins Read

    1000 livros gratuitos sobre programação!

    Olha que dica bacana! A pagina só com livros sobre programação é mantida no GitHub…

    30 APIs Gratuitas para desenvolvedores

    Facebook X (Twitter) Instagram LinkedIn

    Type above and press Enter to search. Press Esc to cancel.

    Vá para versão mobile