What this does is instruct RavenDB to load into the session the Customer and the associated Products into the session, so when you do something like this:

var cust = session.Load<Customer>(order.Customer);

The value will be loaded from the session cache, without going to the sever. As I said, this is a feature that we have had for quite a while, and it is a really nice one, because it drastically reduce the number of queries that you have to make.

The problem is that some people want to take it one step further, they want to be able to search on an Order, but also load the Location of a Product. I don’t really like this, and as I said, when asked for this feature, I consistently said that it isn’t there because it represent a remnant of relational thinking in your design.

But as it turned out, we do support this, although quite by accident.

The reason is quite simple, we evaluate Includes only after we evaluate the TranformResults function. Which means that the TranformResults function gets to choose whatever you want to include. Here is how it works:

If you did associate locations with the order, does that mean you would then have to ensure that the "denormalized" location data is kept up to date whenever a location changes? Assuming you have 20 different models that require location data within them, would that mean writing the same info 20 separate times in application code (write the location change to Model 1, now Model 2, now Model 3, etc.), or is there some way Raven can sync them automatically?

Tyler,
You see the problem, right?
That is the modeling issue.
Either locations are important to the order for another reason, or they aren't.
If they are important, they should be with the order, if they aren't, why do you need tertiary include for it?

I definitely see that, I'm just trying to wrap my head around the maintenance of not having "once source of truth", but twenty sources of truth. I can envision developers that aren't aware of those twenty sources performing updates to some of them, but not all, causing data disparity. Then we have a maintenance nightmare where "location/1" has different Street Address in it than what is in the Order model for the "location/1" Street Address.

Without diving into tertiary relations, since you bring up the temporal issue again: Can you walk through what happens when you want to change orders/1 line for products/1 quantity from 3 to 4? Does orders/1 become orders/2, or do you edit it to have a 3rd line where the original gets marked off with an end date? How do you dive through the indexing to ensure the correct data state for a particular point in time is returned?

I know how to do this with relational data & SQL, just curious how a NoSQL solution changes perspective on this problem.

I don't think it was a good decision to make this an 'official' feature by posting it on your blog. It's still far too complicated, so it will produce lots of confusion when people try to use it. If at all, I would rather have it support syntax like this: