Errata

This statement makes no sense and requires explanation. If I wanted to insure only one result I would use TOP one.

"SingleOrDefault uses the same database query that Find uses when it looks for entities in the database. The SQL selects the TOP two results so that it can ensure there is only one match:"

Note from the Author or Editor:
"The SQL selects the TOP two results so that it can ensure there is only one match. If more than one is returned, then an exception will be thrown."

(To submitter: LINQ singleordefault behavior has not changed since .NET 3.5. It's always been this way. Hopefully added sentence clarifies enough.)

Ref my previous post: (I realize this example works for the case given)

This statement contained within SaveDestinationAndLodging marks all existing Lodging as modified whether or not they were actually modified.

foreach (var lodging in destination.Lodgings)
{
if (lodging.LodgingId > 0)
{
context.Entry(lodging).State = EntityState.Modified;
}
}

To reproduce my result simply comment out any code in TestSaveDestinationAndLodgings() making changes to lodging (addition, deletion, or updating). Since there are 2 lodgings assigned to the Grand Canyon, the 2 lodgings are marked as modified. This will trigger 2 unnecessary trips to the database. Therefore, if the Grand Canyon had a 100 lodgings assigned to it, then, in this case, 100 unnecessary trips to the database are made. I just ran it to doublecheck myself.

Note from the Author or Editor:
oooh sorry. I was looking at example 13 which added one and modified one.
Yes in the case of example 12, you are explicitly marking every lodging as modified and therefore an update command will be sent for every lodging object. That particular example was written by Rowan and I can't speak for him, but my understanding was that he was simply demonstrating how the change tracker works and what you need to do to affect children in a graph. I don't consider it a real world example...not just because of the performance issue you bring up, but when would you want to do that anyway...simply mark everything as modified for no real reason. So you are correct that that particular code can potentially be very problematic and I'm sorry that we didn't explicitly state that the example was purely theoretical to demonstrate behavior, not coding practices.

I clearly understand what is being illustrated in this example. Normally, however, the authors usually point out when code is inefficient, and either they just note it or provides a reference as to how to handle the situation (usually later in the book).

The problem with this example is the eager loading of lodgings. If there were 100 lodgings, there would be 97 unnecessary update statements sent to the database.

I was hoping to find the answer in Chapter 5 (Change Tracker API). It may be there as my experience with EF is limited at this point.

Note from the Author or Editor:
ahhh no. The context knows that there is one lodging to ADD and one lodging to UPDATE. It only creates commands for objects that are anything but Unchanged (Added, Deleted or Modified). Therefore, in this case only two commands will be sent to the database, regardless of how many lodgings were retrieved along with the destination. I'm not sure exactly where this is explained in the DbContext book but I know that I wrote about this extensively in the 1st and 2nd edition of Programming Entity Framework.