This should turn lazy loading off, but it doesn't:
this.ChangeTracker.LazyLoadingEnabled = false;
What makes this problem so much worse is that there seems to be no IncludeAll method in EF core.
Download this sample and run it:
https://www.dropbox.com/s/mimvgvcmibr7em2/EFSQLiteTest.7z?dl=0
Lazy loading has not been turned off despite LazyLoadingEnabled being set to false.
The only way to load the BillingAddress property is to explicitly Include it. This means having to explicitly specify that each child property be loaded and that is far too onerous.
EF Core version: Microsoft.EntityFrameworkCore.Sqlite 2.2.4
Database Provider: Microsoft.EntityFrameworkCore.Sqlite
Operating system: Windows
IDE: Visual Studio 2017 15.9.11
Platform: .NET Core 2.2
Hi @MelbourneDeveloper
By default EF Core does not load related entities and ChangeTracker.LazyLoadingEnabled does not have any impact on that, it's only for configuring whether related entities will be lazy loaded or the default behaviour will apply.
You should also consider to use owned typed https://docs.microsoft.com/en-us/ef/core/modeling/owned-entities Owned entities will be loaded by default with the owner entity, so you don't need to include them explicitly.
@MelbourneDeveloper In addition to the comments from @AndrewBoklashko above, it seems like the main thing that isn't clear here is that lazy-loading being turned off doesn't mean that EF will eagerly load everything. It just means don't lazy-load, even if you have entities that would normally lazy-load.
@ajcvickers this was a misunderstanding on my part. The problem that it is not possible to load all data in one hit still stands though. EF Core at least needs an IncludeAll.
@MelbourneDeveloper As pointed out above, this issue indicates that we believe IncludeAll would be an anti-pattern and we have no plans to implement it. If your model consists of only one aggregate, then once support for aggregates is completed, defining the model as such would result in the equivalent of IncludeAll for that aggregate.
Most helpful comment
@MelbourneDeveloper As pointed out above, this issue indicates that we believe
IncludeAllwould be an anti-pattern and we have no plans to implement it. If your model consists of only one aggregate, then once support for aggregates is completed, defining the model as such would result in the equivalent ofIncludeAllfor that aggregate.