Простой запрос MongoDB для HASH не работает должным образом (только в некоторых условиях) - PullRequest
0 голосов
/ 18 октября 2011

Хорошо, это немного сложно, поэтому я постараюсь быть ясным.

У меня есть структура, которую я использую для создания какой-то системы тикетов.

Коллекция для родителей: Тема

Встроенная коллекция: сообщение (поток содержит 0..N сообщений)

В сообщении у меня есть атрибут read_time типа HASH, где ключи - это OID пользователя, а значения datetime. Пример набора данных для потока будет выглядеть как

_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 
                                               } 
                          } 
                    ] 

Идея состоит в том, чтобы построить запрос только к тем потокам, которые являются UNREAD. для данного автора. В приведенном выше примере пользователь с OID 4d5a62ac29e1676226000050 прочитал первое сообщение цепочки, но не второй (поскольку хэш read_time не содержит записи для ключ "4d5a62ac29e1676226000050").

Мой запрос выглядит так, что довольно просто в моем мнение и должно работать без нареканий но результаты вполне неожиданно ....

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

Проще говоря, я запрашиваю все темы, содержащие хотя бы одно сообщение в котором нет ключа "4d5a62ac29e1676226000050" атрибут read_time.

Странная часть сейчас ... это то, что этот запрос работает, но не всегда! Он возвращает только подмножество потоков, которые я ожидаю увидеть. я еще не удалось определить точную закономерность для случаев, когда не работают, но кажется, что когда есть более одного сообщения в поток и что "многие" другие пользователи прочитали их, но не пользователь Я запрашиваю, тогда соответствующая тема не отображается в результаты ... я понятия не имею, почему. Если я запрашиваю документы вручную Я вижу все данные, которые я ожидаю (как в примере выше), но Нить просто игнорируется ...

Пожалуйста, помогите!

Алекс

1 Ответ

0 голосов
/ 20 февраля 2012

Если я правильно понимаю, вы хотите, чтобы 4e8b281429e167765d00001a, 4d5a7dfe29e1674958000013, 4d5a62ac29e1676226000050 были ключами внутреннего хэша под первым read_time. Но я не вижу двоеточия между (скажем,) 4e8b281429e167765d00001a и 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 
}
...