Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't Disable Lazy Loading #15802

Closed
MelbourneDeveloper opened this issue May 25, 2019 · 5 comments
Closed

Can't Disable Lazy Loading #15802

MelbourneDeveloper opened this issue May 25, 2019 · 5 comments

Comments

@MelbourneDeveloper
Copy link

MelbourneDeveloper commented May 25, 2019

Describe what is not working as expected.

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.

Steps to reproduce

Download this sample and run it:
https://www.dropbox.com/s/mimvgvcmibr7em2/EFSQLiteTest.7z?dl=0

  • Notice that it creates a Person with an Address (BillingAddress).

  • You can see that Entity is created correctly by opening the SQLite file with SQLite DB Browser. The address is created, and Person has a foreign pointing to the Address record.

  • When the Person Entity is loaded, the BillingAddress is null. You will see an exception

  • 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.

Further technical details

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

@AndrewBoklashko
Copy link

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.

#4851 has an explanation of why IncludeAll does not exist.
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.

@ajcvickers
Copy link
Member

@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.

@MelbourneDeveloper
Copy link
Author

MelbourneDeveloper commented May 28, 2019

@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.

@ajcvickers
Copy link
Member

@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.

@BarchSteel
Copy link

I think there are legitimate use-cases for IncludeAll and it should be included in the next EF release.
For example: develop a desktop or cross-platform app that uses a SQLite database to save / load the data from a file. It is perfectly ok to want to load the entire database into memory.

As a work-around, I think this implementation for IncludeAll can be used: https://stackoverflow.com/a/64614824/14855926

@ajcvickers ajcvickers reopened this Oct 16, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants