2011-10-18 1 views
0

Ok, c'est un peu complexe, donc je vais essayer d'être clair.Simple requête MongoDB sur HASH ne fonctionne pas comme prévu (seulement dans certaines conditions)

J'ai une structure que j'utilise pour construire une sorte de système de tickets.

Parent Collection: Fil

Collection Embarqué: Message (un thread Messages 0..n intègre)

Dans un message que j'ai un attribut "read_time" de type HASH où les clés sont les OID d'un utilisateur et les valeurs un datetime. Un échantillon ensemble de données pour une discussion ressemblerait

_id     "4e9806c223349f0001000044" 
author_id   {"$oid": "4e8b281429e167765d00001a"} 
created_at   2011-10-14 09:54:10 UTC 
ref     252 
status  "open" 
... 
messages 
        [ 
         0 
          { 
          _id     {"$oid":  "4e9806c223349f0001000045"} 
          author_id   {"$oid":  "4e8b281429e167765d00001a"} 
          content    "Hello" 
          created_at 2011-10-14 09:54:11 UTC 
          read_time 
               { 
                4e8b281429e167765d00001a   2011-10-14 09:54:11 UTC 
                4d5a7dfe29e1674958000013   2011-10-14 11:48:18 UTC 
                4d5a62ac29e1676226000050  2011-10-15 06:44:21 UTC 
               } 
          }, 
        1 
          { 
          _id     {"$oid": "4e9806c223349f0001000046"} 
          author_id   {"$oid": "4e8b281429e167765d00001a"} 
          content    "Hello 2" 
          created_at 2011-10-14 09:54:11 UTC 
          read_time 
               { 
                4e8b281429e167765d00001a   2011-10-15 09:54:11 UTC 
                4d5a7dfe29e1674958000013   2011-10-16 11:48:18 UTC 
               } 
          } 
        ] 

L'idée ici est de construire une requête pour que les fils qui sont UNREAD pour un auteur donné. Avec l'exemple donné ci-dessus, l'utilisateur avec OID 4d5a62ac29e1676226000050 a lu le premier message du thread mais pas le second (comme le hachage read_time ne contient pas une entrée pour la clé "4d5a62ac29e1676226000050").

Ma requête ressemble aime ça, ce qui est assez simple à mon avis et devrait fonctionner parfaitement, mais les résultats sont tout à fait inattendu ....

{ "support_messages.read_time.4d5a62ac29e1676226000050" : { "$exists" : false} } 

simplement, j'Interroger tous les fils qui contient au moins un message qui n'a pas de clé de "4d5a62ac29e1676226000050" dans son attribut read_time . La partie étrange maintenant ... est que cette requête fonctionne, mais pas tout le temps! Il renvoie uniquement un sous-ensemble des threads que je m'attends à voir. I n'ont pas encore pu déterminer un modèle exact pour les cas où ne fonctionnent pas, mais il semble que lorsqu'il y a plus d'un message dans un thread et que "beaucoup" d'autres utilisateurs les ont lues, mais pas l'utilisateur Je demande, puis le fil en question n'apparaît pas dans les résultats ... Je ne sais pas pourquoi. Si je demande les documents manuellement je vois toutes les données que je m'attends (juste comme l'exemple ci-dessus), mais le fil est simplement ignoré ...

S'il vous plaît, aidez!

Alex

+0

Après beaucoup de tests dans toutes les directions possibles que je pouvais, il semble que la requête suivante fonctionne correctement pour mon but: { « messages » = > {"$ elemMatch" => {"read_time. # {u.id.to_s}" => {"$ existe" => false}}}} Mais cela n'a pas de sens pour moi ...l'ajout de $ elemMatch ne devrait absolument pas faire de différence puisqu'il n'y a qu'un attribut "un" dans la requête ?? Alex – Alex

Répondre

0

Si je comprends bien, vous voulez 4e8b281429e167765d00001a, 4d5a7dfe29e1674958000013, 4d5a62ac29e1676226000050 pour être les clés du hachage interne sous la première read_time. Mais je ne vois pas de deux points entre (disons) 4e8b281429e167765d00001a et 2011-10-14 09:54:11 UTC.

je serais attendre que ce soit:

read_time 
{ 
    4e8b281429e167765d00001a : 2011-10-14 09:54:11 UTC 
    4d5a7dfe29e1674958000013 : 2011-10-14 11:48:18 UTC 
    4d5a62ac29e1676226000050 : 2011-10-15 06:44:21 UTC 
} 
Questions connexes