mongodump - range query on timestamp filed raising FailedToParser Error

Question

The following is the structure of the documents:

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

I am doing the following mongodump query to dump all documents with timestamp greater than November 1, 2013:

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

And it shows:

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

Even though the same query object (except for the backslash used for escaping $gte) works fine in mongo shell. What am I doing wrong?

P.S. the version of MongoDB is 2.4.6

Here's the related MongoDB bug [https://jira.mongodb.org/browse/SERVER-12390] — Kyrstellaine, Nov 18 '14 at 21:01
bug resolved May 15 2015: https://jira.mongodb.org/browse/TOOLS-725 — razon, Jun 10 '15 at 17:09

mu is too short · Accepted Answer · 2013-11-06T07:05:46.627

14

You have a problem with your nested quotes:

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

I'd use single quotes on the outside:

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

That also lets you avoid escaping the $gte too. And if it doesn't like the new Date then you could use:

{$gte: new Date(1383264000000)}

For posterity, it seems that the -q parser doesn't like the three argument form of the Date constructor nor does it like the ISODate function that MongoDB usually uses for dates and timestamps. I get confusing assertions failures like:

Assertion: 10340:Failure parsing JSON string near: timestamp

when I try either of those. This is pretty puzzling to me but sometimes it is better to just quietly walk away once a workable solution is found.

edited Nov 06 '13 at 07:05

answered Nov 06 '13 at 06:49

mu is too short

426,620
70
833
800

1

I got this when I tried your query: `assertion: 16619 code FailedToParse: FailedToParse: First character in field must be [A-Za-z$_]: offset:78` – rubayeet Nov 06 '13 at 06:50
It doesn't like the `new Date(2013, 10, 1)` either? Does it like `ISODate('2013-11-01')` better? – mu is too short Nov 06 '13 at 06:53
1

Got it working by trying this: `{source: "7e04f65e47ed3ddfeb21716a247e3fa6", timestamp: {$gte: new Date(1383264000000)}}` Could you edit your answer so I can accept? Thanks. – rubayeet Nov 06 '13 at 06:54
Updated. Does it take `{$gte: ISODate("2013-11-01")}`? – mu is too short Nov 06 '13 at 06:57
2

Nope: `assertion: 16619 code FailedToParse: FailedToParse: Bad characters in value: offset:62` – rubayeet Nov 06 '13 at 06:59
Wow, that makes no sense at all. I'm actually getting assertion failures from deep inside the JSON parser when I use the three argument Date constructor or ISODate. Wow. – mu is too short Nov 06 '13 at 07:02
1

This is a bug in the parser for mongoexport, https://jira.mongodb.org/browse/SERVER-12390 – tantrix Apr 23 '15 at 18:56

score 0 · Answer 2 · answered Jun 10 '15 at 17:08

0

in my case problem was with different versions of mongodb.

Problem

16619 code FailedToParse: FailedToParse: Bad characters in value: offset

occurred when I tried restore on 2.4 mongodb version backup from 3.0 version.

answered Jun 10 '15 at 17:08

razon

3,882
2
33
46

mongodump - range query on timestamp filed raising FailedToParser Error

2 Answers2