DbContext: Throw for explicit loading of an un-tracked entity

[ljvanschie]

When trying to explicitly load a reference or a collection, the values of these properties will still be null in case you are querying a DbSet with NoTracking behaviour (either by using the .AsNoTracking() extension method or by setting the default query tracking behaviour of the DbContext).

This had me puzzled quite a while, since this is not mentioned in any documentation. Furthermore, I would expect it to also be working when querying data in a read-only way.

Steps to reproduce

Query a DbSet using .AsNoTracking(), explicitly load a reference, and inspect the property.

var item = _context.Items.AsNoTracking().FirstOrDefault(i => i.ItemId == id);
_context.Entry(item).Reference(a => a.ItemGroup).Load();

// item.ItemGroup will still be null

Further technical details

EF Core version: 1.1.0
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
IDE: Visual Studio 2015

[ajcvickers]

@ljvanschie Note for triage: This code is saying to load a relationship for a detached entity. It would be nice if this worked, but I expect is is non-trivial. We should probably throw for now.

[ljvanschie]

Thanks for the quick response @ajcvickers. Sorry if I'm misunderstanding or if my example wasn't clear enough, but in this (simplified) example, ItemGroup is a navigation property and also exists as an entity within the same DbContext. If I change the tracking behaviour, it loads as expected.

I don't see how this is different than the examples in the documentation (https://docs.microsoft.com/en-us/ef/core/querying/related-data#explicit-loading). It's similar to the case for explicitly loading the Owner of a blog post.

-edit: or does using .AsNoTracking() make it a 'detached object' for which explicit loading is just not supported by design? In that case my expectation was wrong and it would be nice if it threw an exception indeed.
I thought using NoTracking was best practice for all read-only queries.

[ajcvickers]

@ljvanschie AsNoTracking results in entities that are not tracked. The Entry method is typically used to get information and perform operations on a tracked object. (It can be used on an object that is not tracked, but the main use for this is to changed its state to make it tracked.) So if you want the services of the context, including additional loading with fixup, then you need to track the entities. That being said, it is not totally unreasonable for Load to work with un-tracked entities, but it would require a different implementation and we will discuss as a team whether or not to do this. If we do decide to do it, it will still likely be low priority and therefore not done soon.

[ljvanschie]

I see, thanks for clearing that up!

[rowanmiller]

Decided that we should throw for the moment, this isn't a scenario we intended to support. We may look at explicit loading for untracked entities in the future, based on customer demand. For the moment, using a tracking query, or eager loading, would be our recommendation.