MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Subdocumento de localização/atualização do Mongoose


Então, como você notou, o padrão no mangusto é que quando você "incorpora" dados em uma matriz como esta, você obtém um _id valor para cada entrada de matriz como parte de suas próprias propriedades de subdocumento. Na verdade, você pode usar esse valor para determinar o índice do item que pretende atualizar. A maneira MongoDB de fazer isso é posicional $ variável do operador, que mantém a posição "combinada" na matriz:
Folder.findOneAndUpdate(
    { "_id": folderId, "permissions._id": permission._id },
    { 
        "$set": {
            "permissions.$": permission
        }
    },
    function(err,doc) {

    }
);

Esse .findOneAndUpdate() retornará o documento modificado ou, caso contrário, você pode simplesmente usar .update() como um método se você não precisar que o documento seja devolvido. As partes principais são "combinar" o elemento do array para atualizar e "identificar" que combinam com o $ posicional como mencionado anteriormente.

Então é claro que você está usando o $set operador para que somente os elementos que você especifica são realmente enviados "pelo fio" para o servidor. Você pode levar isso adiante com "notação de ponto" e apenas especificar os elementos que você realmente deseja atualizar. Como em:
Folder.findOneAndUpdate(
    { "_id": folderId, "permissions._id": permission._id },
    { 
        "$set": {
            "permissions.$.role": permission.role
        }
    },
    function(err,doc) {

    }
);

Portanto, esta é a flexibilidade que o MongoDB oferece, onde você pode ser muito "direcionado" em como você realmente atualiza um documento.

O que isso faz, no entanto, é "ignorar" qualquer lógica que você possa ter incorporado ao seu esquema "mangusto", como "validação" ou outros "ganchos de pré-salvamento". Isso ocorre porque a maneira "ótima" é um "recurso" do MongoDB e como ele é projetado. O próprio Mongoose tenta ser um invólucro de "conveniência" sobre essa lógica. Mas se você estiver preparado para assumir algum controle, as atualizações podem ser feitas da maneira mais otimizada.

Portanto, sempre que possível, mantenha seus dados "incorporados" e não use modelos referenciados. Ele permite a atualização atômica de itens "pais" e "filhos" em atualizações simples, nas quais você não precisa se preocupar com a simultaneidade. Provavelmente é uma das razões pelas quais você deveria ter selecionado o MongoDB em primeiro lugar.