Errata

MongoDB Applied Design Patterns

Errata for MongoDB Applied Design Patterns

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
PDF Page 5
United States

Table 1-4

The id for Jenny should be 3 and not 2.

AdronRBO  Feb 28, 2014 
Printed Page 14
last python block and accompanying schemas

In the many-to-many "compromise" example that concludes Chapter 1, the db.category schema uses the category name for its _id and the db.product schema references that category name/id in its "category_ids" array. Why then is the second query needed in get_product_with_categories? Wouldn't we already have this data returned into the "product" result set?

Anonymous  Jul 10, 2013 
Printed Page 22
Last paragraph and json snippet, continuing until Conclusion heading

The snippet of JSON shows an example of property-value pairs for storing semi-structured domain data.

{
_id: ObjectId(...),
price: 499.99,
title: 'Big and Fast Disk Drive',
gb_capacity: 1000,
properties: [
['Seek Time', '5ms'],
['Rotational Speed', '15k RPM'],
['Transfer Rate', '...']],
...
]
}

It talks about using property-value pairs, which are presented as two-element arrays within the "properties" array, which an index for on the following page (23). Then it gives an example of a query:

db.Products.find({'properties': [ 'Seek Time': '5ms' ]})

So there's this mixed up square vs curly bracket type. Does this mean that the property-value pairs should be objects instead of two-element arrays, like so?

properties: [
{ 'Seek Time': '5ms' },
{'Rotational Speed', '15k RPM' },
// etc.
]

Anonymous  Oct 18, 2013 
Printed, PDF, ePub, Mobi Page 94
code sample

The way function add_item_to_cart(...) is implemented can result in inconsistent DB state, without any chance of detecting/fixing the error. In particular, what if DB becomes unavailable (e.g. persistent network error) after item is added to cart, but before inventory is updated? That is, what if first db.cart.update succeeds, but subsequent db.product.update fails? And because we are talking about persistent network error, the final db.cart.update also fails?

The right way to do this would be to reverse the order: first update the inventory (i.e. allocate the item), and only after that add it to cart. This is pretty obvious, and I was really surprised to see such an obvious blunder in the otherwise well written book.

In fact, section "Error handling" p.98 sheds some light on this problem. The authors say that

"The previous operations do not account for one possible failure situation. If an exception
occurs after updating the shopping cart but before updating the inventory collection,
then we have an inconsistent situation where there is inventory ?trapped? in a shopping
cart."

Very good! But the "solution" proposed by authors does not solve this problem!

In the following paragraph the authors say:

"To account for this case, we?ll need a periodic cleanup operation that finds inventory
items that have carted items and check to ensure that they exist in some user?s active
cart"

This is wrong!! How can you fix orphan items in the CART by looking at INVENTORY documents?? In our failure scenario, we first put items into cart, but we could not update inventory because some network error occurred. So, there would be NO CARTED items in the inventory which has not been put to cart as well.

It looks like this section was "copy-and-pasted" from multiple early revisions of the book, but the authors forgot to check the whole chapter for consistency.



Alexey Smirnov  Jul 09, 2014 
PDF Page 144
code example, followers array

see

"Independent Collections"
[ ... ]
{
[ ... ],
followers: {
"T4Y...AD": { name: 'Jared', circles: [ 'python', 'authors'] },
"T4Y...AF": { name: 'Bernie', circles: [ 'python' ] },
"T4Y...AI": { name: 'Meghan', circles: [ 'python', 'speakers' ] },
...
],

The followers object begins as an "object" { but ends as "array" ]
It should be an object ...

while one question remains for me ;)
How would such a structure look in a mongoose schema ("populate") ?

Sebastian Lasse  Apr 22, 2014