J'ai donc pu contourner ce problème en modifiant la requête pour rechercher un champ qui est mis à jour en même temps mais qui n'est pas imbriqué. Je pense que le problème avec la vérification d'un champ imbriqué est que le ChangeEvent
updateDescription
de propriété ne contient pas l'objet imbriqué réel qui a changé ; à la place, il contient la représentation par point du changement. Donc, si vous regardez la Mise à jour 2 dans mon message, vous verrez que updatedFields
a cette valeur :{\"someOtherField\":310,\"message.fansNo\":1...
au lieu de {\"someOtherField\":310,\"message\":{\"fansNo\":1...
. En utilisant message.fansNo
dans la requête $match, Mongo recherchera cette forme d'objet :{\"message\":{\"fansNo\":1...
, ce qui ne correspond pas dans ce cas. Une "vraie" solution ici pourrait être d'échapper au .
dans message.fansNo
dans mon expression de correspondance, mais je n'ai pas réussi à le faire fonctionner (voir ce fil
).
Donc, la "solution" qui a fonctionné pour moi n'est vraiment qu'une solution de contournement qui fonctionne pour mon cas d'utilisation spécifique :il se trouve que someOtherField
est toujours mis à jour avec message.fansNo
, et someOtherField
n'est pas imbriqué. Je peux donc faire correspondre someOtherField
sans se soucier de la nidification. Fondamentalement, cette expression de correspondance me donne les résultats souhaités :
{
"$or": [
{
"updateDescription.updatedFields.someOtherField": {"$exists":true}
},
{
"updateDescription.updatedFields.someOtherField":{"$exists":true}
}
]
}
J'espère que cela aidera quelqu'un d'autre !