Mongoose: Retirer le crochet non déclenché lors de la suppression de documents

cela fonctionne comme prévu. c'est la même chose pour Model.update . aucun middleware n'est appelé b/c middleware ne s'exécute que sur des documents mongoose qui ne sont pas impliqués lors de l'envoi d'une commande remove directement à MongoDB via l'utilisation de Model.remove() .

Je vais laisser cela ouvert pour le moment jusqu'à ce que je corrige les Model.remove docs pour qu'ils soient en ligne avec Model.update . Merci pour l'information.

Je vois. Existe-t-il un moyen de se connecter aux opérations de suppression de _all_ ?

pas actuellement.

D'accord. Merci!

eh bien tu cool si tu as patché Model.remove mais c'est à toi de voir :)

Ne fonctionne pas avec findOneAndRemove

Ne semble pas non plus fonctionner lorsque vous appelez Model.remove(_id).exec();

Voici comment j'ai contourné le problème :

Post.findOneAndRemove({'id': data.post, 'user.uid': socket.handshake.user.id}, function(err, post) {
    post.remove();
});

models.js

postSchema.post('remove', function(doc) {
    console.log('removed');
});

// prints 'removed' once

Le crochet de suppression n'est pas déclenché sur findOneAndRemove, cependant, cela fonctionne lorsque j'appelle remove dans le rappel

D'accord mais pourquoi ? Je suis désolé, je n'ai pas compris pourquoi le crochet est exécuté sur Model.remove() et non sur Query.remove(). Maintenant, pourquoi devrais-je utiliser les crochets s'ils ne sont pas appelés à chaque fois ?
quel en est l'usage ?

Je veux dire : dois-je utiliser les crochets et éviter Query.remove ou ne pas utiliser les crochets et toujours supprimer manuellement ?

@Darksheep42 si vous souhaitez utiliser des crochets, utilisez doc.remove() . La raison pour laquelle des choses comme MyModel.remove(); ne prennent pas en charge les crochets est que le document supprimé peut ne pas exister en mémoire, vous devrez donc d'abord interroger mongodb pour le document, puis dire à mongodb de le supprimer pour que les crochets fonctionnent correctement. .

Serait-il possible d'ajouter la prise en charge des crochets Query.remove() maintenant avec le middleware de requête en 4.0 ?

Pas pour le moment - c'est très délicat car il existe déjà un middleware pour Model.remove()

Y aurait-il un problème autre que le conflit de nom? Ne pourriez-vous pas simplement appeler le crochet « retirer-requête » ou quelque chose au lieu de « supprimer » ?

Ou que diriez-vous de faire ce que vous semblez faire avec update - appelez le crochet de requête même lorsque la version doc de la fonction est utilisée. Bien sûr, cela briserait la compatibilité descendante, mais c'est une idée.

Cela semble être une idée raisonnable, mais j'hésite à casser l'API à moins qu'il n'y ait une très bonne raison de le faire. À l'heure actuelle, le crochet de suppression opère sur un document, donc le contexte dans le middleware est le document. Pour les Query.remove() généraux, le document peut même ne pas être en mémoire. Je suppose que nous pourrions le nommer autrement comme 'remove-query , but that's nasty. What do you think about adding an extra options arg to pre() and post()`, quelque chose comme :

schema.pre('remove', { query: true }, function() {
  // This is only attached as query middleware
});

schema.pre('remove', { doc: true }, function() {
  // This will not run on Query.remove(), only doc.remove()
});

Je suppose que cela pourrait fonctionner. C'est probablement mieux que d'utiliser un nom différent et cela ne casse pas l'API. Donc je suppose que si quelqu'un l'a fait

schema.pre('remove', { query: true, doc: true }, function() {

});

Le hook serait appelé à la fois sur les requêtes de requête et de documentation. Je suppose qu'un utilisateur pourrait le faire s'il ne se souciait pas du contexte. Si vous faites cela, cependant, vous voudrez probablement aussi changer le crochet update pour correspondre à ce nouveau style, et cela pourrait potentiellement casser le code des gens.

Ouais, le plus délicat dans ce contexte est "quelle est la valeur par défaut ?" Afin de préserver l'API, nous devrions faire en sorte que update soit un middleware de requête par défaut, mais remove est un middleware de document par défaut. Ce sera très bizarre. Je pense que nous devrions simplement ouvrir un problème séparé pour 5.0 et nous en préoccuper plus tard :)

Que diriez-vous, juste pour la prochaine version ou une version dans un proche avenir, nous pouvons simplement appeler le crochet « remove-query » ou quelque chose du genre ? Cela ne casse pas l'API et AFAIK devrait être assez facile à mettre en œuvre. Nous pourrions vraiment utiliser cette fonctionnalité, car pour le moment, vous ne pouvez pas capturer 100% des demandes de suppression via un middleware et nous préférons de loin le faire plutôt que d'appliquer certaines techniques dans notre base de code. Dans 5.0, nous pouvons le faire "de la bonne manière", mais j'aimerais juste voir cet ajout rapide avant la v5.

Approche alternative : que diriez-vous de créer une fonction preQuery() et postQuery() ?

Alors au lieu d'écrire

schema.pre('remove', function() {
    // What is this? A doc hook? A query hook? Idk man
});

tu écrirais

schema.preQuery('remove', function() {
    // This is definitely a query hook
});
schema.pre('remove', function() {
    // This must be a doc hook
});

Alors, pre seraient-ils réservés aux docs ? De plus, je suppose que vous pourriez mettre cela dans une version 4.x sans casser l'API, mais nous voudrions probablement supprimer l'ancien style pre pour le middleware de requête dans 5.0.

Oui, preQuery() serait un bon moyen de préserver l'API jusqu'à ce que nous puissions trouver une API plus propre. J'imagine que preQuery() pourrait être obsolète immédiatement, car je ne suis pas tout à fait ravi de la syntaxe.

Ce problème est toujours ouvert, est-il résolu ?
Qu'en est-il de la pré-requête ?

Le problème de la pré-suppression des documents par rapport aux requêtes est suivi dans #3054, pas encore implémenté, les PR sont les bienvenus.