mongodump — запрос диапазона по временной метке, вызывающий ошибку FailedToParser

Структура документов следующая:

{
  "_id" : ObjectId("4fccd39c9d8597a034d183b1"),
  "image" : "23ef514f8201320c2d7253e4bf28edf6",
  "owner" : "1b8c335c902ac4ab128ee8ed773bee04",
  "pageviews" : 57,
  "source" : "b1b3849b472edada1b922c786df5b46f",
  "timestamp" : ISODate("2012-06-04T00:00:00Z")
}

Я делаю следующий запрос mongodump, чтобы вывести все документы с timestamp больше, чем 1 ноября 2013 года:

mongodump -d dbname -c coll_name -q "{source: "7e04f65e47ed3ddfeb21716a247e3fa6", timestamp: {\$gte: new Date(2013, 10, 1)}}"

И это показывает:

assertion: 16619 code FailedToParse: FailedToParse: Expecting '}' or ',': offset:13

Несмотря на то, что тот же объект запроса (за исключением обратной косой черты, используемой для экранирования $gte) отлично работает в оболочке mongo. Что я делаю не так?

P.S. версия MongoDB 2.4.6


mongodb mongodump
person rubayeet    schedule 06.11.2013    source источник
comment
Вот связанная ошибка MongoDB [jira.mongodb.org/browse/SERVER-12390]   -  person Kyrstellaine    schedule 19.11.2014
comment
ошибка устранена 15 мая 2015 г.: jira.mongodb.org/browse/TOOLS-725   -  person razon    schedule 10.06.2015

Ответы (2)


arrow_upward
14
arrow_downward

У вас проблема с вложенными кавычками:

mongodump -d dbname -c coll_name -q "{source: "7e04f65e47ed3ddfeb21716a247e3fa6", timestamp: {\$gte: new Date(2013, 10, 1)}}"
# ----------------------------------^---------^

Я бы использовал одинарные кавычки снаружи:

mongodump -d dbname -c coll_name -q '{source: "7e04f65e47ed3ddfeb21716a247e3fa6", timestamp: {$gte: new Date(2013, 10, 1)}}'

Это также позволяет вам избежать выхода из $gte. И если ему не нравится new Date, вы можете использовать:

{$gte: new Date(1383264000000)}

Для потомков кажется, что синтаксическому анализатору -q не нравится ни трехаргументная форма конструктора Date, ни функция ISODate, которую MongoDB обычно использует для дат и временных меток. Я получаю запутанные утверждения, такие как:

Assertion: 10340:Failure parsing JSON string near: timestamp

когда я пробую любой из них. Это довольно озадачивает меня, но иногда лучше просто тихо уйти, как только будет найдено работающее решение.

person mu is too short    schedule 06.11.2013
comment
Я получил это, когда попробовал ваш запрос: assertion: 16619 code FailedToParse: FailedToParse: First character in field must be [A-Za-z$_]: offset:78 - person rubayeet; 06.11.2013
comment
Ему тоже не нравится new Date(2013, 10, 1)? Ему больше нравится ISODate('2013-11-01')? - person mu is too short; 06.11.2013
comment
Получил работу, попробовав это: {source: "7e04f65e47ed3ddfeb21716a247e3fa6", timestamp: {$gte: new Date(1383264000000)}} Не могли бы вы отредактировать свой ответ, чтобы я мог принять его? Спасибо. - person rubayeet; 06.11.2013
comment
Обновлено. Требуется ли {$gte: ISODate("2013-11-01")}? - person mu is too short; 06.11.2013
comment
Нет: assertion: 16619 code FailedToParse: FailedToParse: Bad characters in value: offset:62 - person rubayeet; 06.11.2013
comment
Вау, это вообще не имеет смысла. На самом деле я получаю ошибки утверждения из глубины синтаксического анализатора JSON, когда использую конструктор даты с тремя аргументами или ISODate. Ух ты. - person mu is too short; 06.11.2013
comment
Это ошибка в парсере для mongoexport, jira.mongodb.org/browse/SERVER-12390< /а> - person tantrix; 23.04.2015

arrow_upward
0
arrow_downward

в моем случае проблема была с разными версиями mongodb.

Проблема

Код 16619 FailedToParse: FailedToParse: недопустимые символы в значении: смещение

произошло, когда я попытался восстановить резервную копию версии 2.4 mongodb из версии 3.0.

person razon    schedule 10.06.2015