Errata

Or if you?re on Windows, run this: $ mongod.exe

Obviously the $ is UNIX not windows

Note from the Author or Editor:
Good point, it should be:

> mongod.exe

"the document is returned because 25 matches the first clause (it is greater than 25)"
should be changed to
"the document is returned because 25 matches the first clause (it is greater than 10)"

Code : > var timeRemoves = function() {

Please help check.
It should be
> db.tester.findOne();


Tested:
> db.findOne();
Wed May 22 12:44:59.420 JavaScript execution failed: TypeError: Property 'findOne' of object test is not a function
> db.tester.findOne();
{
"_id" : ObjectId("519c5a2b96aa44edfb12e196"),
"foo" : "bar",
"baz" : 456255,
"z" : -456245
}
>

Note from the Author or Editor:
... db.findOne(); // makes sure the remove finishes before continuing
should be:
... db.tester.findOne(); // makes sure the remove finishes before continuing

The follow code isn't correct

db.movies.find({"genre" : "horror"},
... {"$push" : {"top10" : {
... "$each" : [{"name" : "Nightmare on Elm Street", "rating" : 6.6},
... {"name" : "Saw", "rating" : 4.3}],
... "$slice" : -10,
... "$sort" : {"rating" : -1}}}})

The correct code is

db.movies.update({"genre" : "horror"},
{"$push" : {"top10" : {
"$each" : [{"name" : "Nightmare on Elm Street", "rating" : 6.6},
{"name" : "Saw", "rating" : 4.3}],
"$slice" : -10,
"$sort" : {"rating" : -1}}}})

With "update" instead "find"

db.blog.update should be db.blog.posts.update in both examples.

In this example there, actually this part:
var page2 = db.foo.find({"date" : {"$gt" : latest.date}});
should be:
var page2 = db.foo.find({"date" : {"$lt" : latest.date}});
because the whole example is talking about retrieving and
displaying documents in descending order based on "date".
So for the second page, we should use "$lt", and not "$gt".

Regarding finding a random document in a collection, this line is incorrect:
result = db.foo.findOne({"random" : {"$lt" : random}})

The author is using it guard against the case where the random number is bigger than the largest random key of documents in the collection. However, it will also fail to match (return null) if the only documents in the collection have random key values equal to the random number in the search criteria.

The solution is the use "$lte" instead of "$lt".

This code fragment
db.foo.find(criteria)._addSpecial("$maxscan", 20)
should actually read
db.foo.find(criteria)._addSpecial("$maxScan", 20)
because $maxscan does not seem to work i.e.
it does not limit anything. $maxScan does.
It is case-sensitive.

Note from the Author or Editor:
Change both instances of $maxscan to $maxScan.

There's this text on page 76:

"A database command always returns a document containing the key "ok". If "ok"is 1, the command was successful; and if it is 0, the command failed for some reason."

But the code examples on pages 75-77 are not consistent with respect to the ok values. Some show true/false, some show 1/0.

Note from the Author or Editor:
This should be changed to say that ok always indicates success or failure, either with true/false or 1/0.

change "If "ok" is 1, the command was successful; and if it is 0, the command failed for some reason." to "If "ok" is a true value (1, 1.0, or true)
then the command was successful. If it is false then the command failed for some reason."

"However, indexes have their price: every write (insert, update, or delete) will take longer for every index you add."

Actually for updates isn't it true that it has an additional price only if the update updates a field which is part of the keys of some index? I think it is so but I am not 100% sure. I don't see why updating a field which is part of none of the indexes will have an additional price (price for reorganizing some of the indexes).

Note from the Author or Editor:
It depends. If the update makes the document bigger and it has to be moved, then all of the indexes must be updated. But in other cases you are correct. This should be clarified.

However, indexes have their price: every write (insert, update, or delete) will take longer for every Introduction to index you add"
should be:
"However, indexes have their price: every write that touches an indexed field (insert, update, or delete) will take longer for every index you add"

This paragraph has incorrect find statements:

When running "$in" queries there is no way, other than sorting, to control the order of documents returned. For example, {"x" : [1, 2, 3]} will return documents in the same order as {"x" : [3, 2, 1]}.

It's missing the $in operator. It should be:

When running "$in" queries there is no way, other than sorting, to control the order of documents returned. For example, {"x" : {$in, [1, 2, 3]}} will return documents in the same order as {"x" : {$in, [3, 2, 1]}}.

Note from the Author or Editor:
Almost, it should be:

For example, {"x" : {"$in" : [1, 2, 3]}} will return documents in the same order as {"x" : {"$in" : [3, 2, 1]}}.

Collection name is missing in the code:

> db.ensureIndex( ...

should be, for example:

> db.users.ensureIndex( ...

Note from the Author or Editor:
Whoops.

Figure 6-2 is inconsistent with Figure 6-1. In 6-1 the left-hand snowflake is older than the right-hand-snowflake, so in 6-2 the left-hand snowflake should be replaced by the new document.

Note from the Author or Editor:
I think the illustrators must have translated it incorrectly from the original. You're actually the first one to notice in two editions!

"You cannot use a multikey field for any of the prefix or postfix index fields."

I tested this by creating a collection which has these fields:
"dt" : some integers here in the different docs (one integer per doc)
"txt" : some texts here (one text/string per doc)
"author" : some texts/strings, one per doc (but also an array of integers in just one of the documents)

Then I am able to do

db.blog.ensureIndex({"dt" : 1, "txt" : "text", "author" : 1});

contrary to what the book says. I mean, "author" is a postfix field here,
it is multikey (as it contains an array), but I can still create this index.

Seems either I am missing something, or maybe something has
changed since the book was written. I am testing this on version 2.4.8.

Note from the Author or Editor:
Remove the sentence "You cannot use a multikey field for any of the prefix or postfix index fields."

There are two operators that can be used to compute numeric val‐
ues from fields: "$sum"and "$average".

Here this "$average" should read "$avg".

On the next page 136, it is correctly written as "$avg".

In the output from $unwind,
I think that "results" should read "result"
(unless it was otherwise in previous versions of
MongoDB; I tested it in version 2.4.8).