mongodump - range query on timestamp filed raising FailedToParser Error
Asked Answered
A

2

5

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

Acrimonious answered 6/11, 2013 at 6:45 Comment(2)
Here's the related MongoDB bug [jira.mongodb.org/browse/SERVER-12390]Chladek
bug resolved May 15 2015: jira.mongodb.org/browse/TOOLS-725Townley
C
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.

Cleanly answered 6/11, 2013 at 6:49 Comment(7)
I got this when I tried your query: assertion: 16619 code FailedToParse: FailedToParse: First character in field must be [A-Za-z$_]: offset:78Acrimonious
It doesn't like the new Date(2013, 10, 1) either? Does it like ISODate('2013-11-01') better?Cleanly
Got it working by trying this: {source: "7e04f65e47ed3ddfeb21716a247e3fa6", timestamp: {$gte: new Date(1383264000000)}} Could you edit your answer so I can accept? Thanks.Acrimonious
Updated. Does it take {$gte: ISODate("2013-11-01")}?Cleanly
Nope: assertion: 16619 code FailedToParse: FailedToParse: Bad characters in value: offset:62Acrimonious
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.Cleanly
This is a bug in the parser for mongoexport, jira.mongodb.org/browse/SERVER-12390Niggard
T
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.

Townley answered 10/6, 2015 at 17:8 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.