Então, consegui contornar esse problema alterando a consulta para observar um campo que é atualizado ao mesmo tempo, mas não está aninhado. Acho que o problema com a verificação de um campo aninhado é que o
ChangeEvent 's updateDescription não contém o objeto aninhado real que foi alterado; em vez disso, ele contém a representação de notação de ponto da alteração. Então, se você olhar para Atualização 2 no meu post você verá que updatedFields tem este valor:{\"someOtherField\":310,\"message.fansNo\":1... em vez de {\"someOtherField\":310,\"message\":{\"fansNo\":1... . Usando message.fansNo na consulta $match, o Mongo procurará esta forma de objeto:{\"message\":{\"fansNo\":1... , que não corresponde neste caso. Uma solução "real" aqui poderia ser escapar do . em message.fansNo na minha expressão de correspondência, mas não consegui fazer isso funcionar (consulte este tópico
). Portanto, a "solução" que funcionou para mim é realmente apenas uma solução alternativa que funciona para meu caso de uso específico:acontece que
someOtherField é sempre atualizado junto com message.fansNo , e someOtherField não está aninhado. Para que eu possa corresponder a someOtherField sem se preocupar com o aninhamento. Basicamente, essa expressão de correspondência me dá os resultados que eu quero:{
"$or": [
{
"updateDescription.updatedFields.someOtherField": {"$exists":true}
},
{
"updateDescription.updatedFields.someOtherField":{"$exists":true}
}
]
}
Espero que isso ajude mais alguém!
