ANyways, thanks for the suggestion. Will look into it

Trying to use mongoDump’s query ability to create incremental database dumps and hit a roadblock.

A query in the form of
>db.oplog.rs.find({ts:{‘$gte’:Timestamp(ISODate(“2012-01-20 20:15:27″),9899)}})
works perfectly in a mongo shell, however won’t work in mongoDump.
>mongodump –port 8011 -o tran –db local –collection oplog.rs -q ‘{ts:{‘$gte’:Timestamp(ISODate(“2012-01-20 20:15:27″),9899)}}’connected to: 127.0.0.1:8011Fri Feb  3 17:08:59 Assertion: 10340:Failure parsing JSON string near: ts:{:Times0x5817f2 0x5282f4 0x52866e 0xaa151b 0xa97e6d 0xa9be02 0x3d44e1d994 0x4fdfd9 mongodump(_ZN5mongo11msgassertedEiPKc+0×112) [0x5817f2] mongodump(_ZN5mongo8fromjsonEPKcPi+0×444) [0x5282f4] mongodump(_ZN5mongo8fromjsonERKSs+0xe) [0x52866e] mongodump(_ZN4Dump3runEv+0x33b) [0xaa151b] mongodump(_ZN5mongo4Tool4mainEiPPc+0x169d) [0xa97e6d] mongodump(main+0×32) [0xa9be02] /lib64/libc.so.6(__libc_start_main+0xf4) [0x3d44e1d994] mongodump(__gxx_personality_v0+0x3c9) [0x4fdfd9]assertion: 10340 Failure parsing JSON string near: ts:{:Times
This is version 2.0.2.

Is this a bug? Can you suggest a work around?

Also, I realize that mongoDump version 2.1 added $timestamp capability for pulling partial oplog but I couldn’t find any documentation of its usage and syntax. Can you shed some light on this?

You help is truely appreicated.

Regards,
Addie

Yo ho ho, I’m glad you were able to get a copy.  If you’d like a copy, please ask bookstores to carry it if you can’t find it on their shelves (that helps them know to order more MongoDB books).

You probably work on the PHP driver for MongoDB. You could help me a little (and MongoDB for that matter). And no, I am not asking for “private support”. I am currently using PostgreSQL for creating a small website of my own based on a PHP development framework named QCubed ( http://qcu.be/ ). The framework relies heavily on something called ‘code generation’. Speaking briefly about it, code generation would read in all the catalog info and create an ORM layer in PHP for the databases. A few examples: http://examples.qcu.be would help understand. 

Now, I am keen on MongoDB and want to use it later on. Have a 1.8 installation running on my machine too (although I dont get enough time to play around). Since MongoDB comes the closest to SQL while remaining in the NoSQL world, I thought about creating a virtual mapper for QCubed which could take in the Schema of a RDBMS and apply it to the collections on Mongo. Of course the driver can be used to add any additional data in any structure within the documents. Doing the RDBMS to MongoDB mapping has a little benefits of its own:

1. We are effectively using the transactional ability of an RDBMS with the speeds and flexibility of Mongo. So in case some data gets irrecoverable with Mongo, the RDBMS is always there. Plus, RDBMS will handle all the writes ONLY, making Mongo do all the tough job. This will effectively use RDBMS for transactional abilities and MongoDB for all the speed. Also, mongo could be used for gathering and analyzing statistical data and logs in realtime. 

2. With MySQL on a Blackhole engine, only MongoDB will work while schema changes will just require the schema change in MySQL. Blackhole engine will destroy incoming data so no extra space consumption (if so be the need). 

3. IIRC, mongoDB will create a new Key or Collection if I happen to mis-spell any. With QCubed, all tables are accessed via ORM Objects. Spelling mistakes will be next to dead (unless someone issued a custom query). 

4. I plan to make it a write twice, read once model – wherein the data is saved to both the RDBMS as well as Mongo and the read is preferably done only via Mongo and fallbacks reads are done from the RDBMS (such as when reading from secondaries to whom the changes have not propagated yet, but we know that the data was inserted). 

All of this is going to require a lot of insight, specially in the querying mechanism. With recent development, I think it would be easier but a help is surely appreciated from you / the MongoDB team. 

Regards

Using the examples you provide, here are some alternative solutions:Example 1:alternative is to get all the posts by user, then go out and get all the related posts and assemble.  If there were a significant number of posts, the alternative might be slower due to sending lots of data across the wire.Example 2:alternative same as 1 but would probably be much faster since 

Example 3:
alternative would simply do the aggregation against the comments collection and the posts collection would never come into play.  I am guessing this will be a lot faster.

Are my assumptions correct?  

Thanks,

George G.