Plan for Entity Framework Core 5.0

08/22/2020

9 minutes to read

+2



In this article

As described in the planning process, we have gathered input from stakeholders into a tentative plan for the EF Core 5.0 release.

Important This plan is still a work-in-progress. Nothing here is a commitment. This plan is a starting point that will evolve as we learn more. Some things not currently planned for 5.0 may get pulled in. Some things currently planned for 5.0 may get punted out.

General information

EF Core 5.0 is currently scheduled for release at the same time as .NET 5.0. The version "5.0" was chosen to align with .NET 5.0.

Supported platforms

EF Core 5.0 is planned to run on any .NET Standard 2.1 platform, including .NET 5.0. This is part of the more general .NET wide convergence of platforms to .NET Core.

EF Core 5.0 will not run on .NET Framework.

Breaking changes

EF Core 5.0 will contain some breaking changes, but these will be much less severe than was the case for EF Core 3.0. Our goal is to allow the vast majority of applications to update without breaking.

It is expected that there will be some breaking changes for database providers, especially around TPT support. However, we expect the work to update a provider for 5.0 will be less than was required to update for 3.0.

Themes

We have extracted a few major areas or themes which will form the basis for the large investments in EF Core 5.0.

Fully transparent many-to-many mapping by convention

Lead developers: @smitpatel, @AndriySvyryd, and @lajones

Tracked by #10508

T-shirt size: L

Status: Done

Many-to-many is the most requested feature (~506 votes) on the GitHub backlog.

Support for many-to-many relationships can be broken down into three major areas:

Skip navigation properties--covered by the next theme.

Property-bag entity types. These allow a standard CLR type (e.g. Dictionary ) to be used for entity instances such that an explicit CLR type is not needed for each entity type. Tracked by #9914.

) to be used for entity instances such that an explicit CLR type is not needed for each entity type. Tracked by #9914. Sugar for easy configuration of many-to-many relationships.

In addition to the skip navigation support, we are now pulling these other areas of many-to-many into EF Core 5.0 so as to provide a complete experience.

Many-to-many navigation properties (a.k.a "skip navigations")

Lead developers: @smitpatel and @AndriySvyryd

Tracked by #19003

T-shirt size: L

Status: Done

As described in the first theme, many-to-many support has multiple aspects. This theme specifically tracks use of skip navigations. We believe that the most significant blocker for those wanting many-to-many support is not being able to use the "natural" relationships, without referring to the join table, in business logic such as queries. The join table entity type may still exist, but it should not get in the way of business logic.

Table-per-type (TPT) inheritance mapping

Lead developer: @AndriySvyryd and @smitpatel

Tracked by #2266

T-shirt size: XL

Status: Done

We're doing TPT because it is both a highly requested feature (~289 votes; 3rd overall) and because it requires some low-level changes that we feel are appropriate for the foundational nature of the overall .NET 5 plan. We expect this to result in breaking changes for database providers, although these should be much less severe than the changes required for 3.0.

Filtered Include

Lead developer: @maumar

Tracked by #1833

T-shirt size: M

Status: Done

Filtered Include is a highly-requested feature (~376 votes; 2nd overall) that isn't a huge amount of work, and that we believe will unblock or make easier many scenarios that currently require model-level filters or more complex queries.

Split Include

Lead developer: @smitpatel

Tracked by #20892

T-shirt size: L

Status: Done

EF Core 3.0 changed the default behavior to create a single SQL query for a given LINQ query. This caused large performance regressions for queries that use Include for multiple collections.

In EF Core 5.0, we are retaining the new default behavior. However, EF Core 5.0 will now allow generation of multiple queries for collection Includes where having a single query is causing bad performance.

Required one-to-one dependents

Lead developers: @AndriySvyryd and @smitpatel

Tracked by #12100

T-shirt size: M

Status: Done

In EF Core 3.0, all dependents, including owned types are optional (e.g. Person.Address can be null). In EF Core 5.0, dependents can be configured as required.

Rationalize ToTable, ToQuery, ToView, FromSql, etc

Lead developers: @AndriySvyryd and @smitpatel

Tracked by #17270

T-shirt size: L

Status: Done

We have made progress in previous releases towards supporting raw SQL, keyless types, and related areas. However, there are both gaps and inconsistencies in the way everything works together as a whole. The goal for 5.0 is to fix these and create a good experience for defining, migrating, and using different types of entities and their associated queries and database artifacts. This may also involve updates to the compiled query API.

Note that this item may result in some application-level breaking changes since some of the functionality we currently have is too permissive such that it can quickly lead people into pits of failure. We will likely end up blocking some of this functionality together with guidance on what to do instead.

General query enhancements

Lead developers: @smitpatel and @maumar

Tracked by issues labeled with area-query in the 5.0 milestone

T-shirt size: XL

Status: Done

The query translation code was extensively rewritten for EF Core 3.0. The query code is generally in a much more robust state because of this. For 5.0 we aren't planning on making major query changes, outside those needed to support TPT and skip navigation properties. However, there is still significant work needed to fix some technical debt left over from the 3.0 overhaul. We also plan to fix many bugs and implement small enhancements to further improve the overall query experience.

Migrations and deployment experience

Lead developers: @bricelam

Tracked by #19587

T-shirt size: L

Status: Scoped/Done

Scoping: The migrations bundles feature has been deferred until after the EF Core 5.0 release. However, several other targeted improvements related to migrations will be included in EF Core 5.0

Currently, many developers migrate their databases at application startup time. This is easy but is not recommended because:

Multiple threads/processes/servers may attempt to migrate the database concurrently

Applications may try to access inconsistent state while this is happening

Usually the database permissions to modify the schema should not be granted for application execution

It's hard to revert back to a clean state if something goes wrong

We want to deliver a better experience here that allows an easy way to migrate the database at deployment time. This should:

Work on Linux, Mac, and Windows

Be a good experience on the command line

Support scenarios with containers

Work with commonly used real-world deployment tools/flows

Integrate into at least Visual Studio

The result is likely to be many small improvements in EF Core (for example, better Migrations on SQLite), together with guidance and longer-term collaborations with other teams to improve end-to-end experiences that go beyond just EF.

EF Core platforms experience

Lead developers: @roji and @bricelam

Tracked by #19588

T-shirt size: L

Status: Scope/Done

Scoping: Platform guidance and samples are published for Blazor, Xamarin, WinForms, and WPF. Xamarin and other AOT/linker work is now planned for EF Core 6.0.

We have good guidance for using EF Core in traditional MVC-like web applications. Guidance for other platforms and application models is either missing or out-of-date. For EF Core 5.0, we plan to investigate, improve, and document the experience of using EF Core with:

Blazor

Xamarin, including using the AOT/linker story

WinForms/WPF/WinUI and possibly other U.I. frameworks

This is likely to be many small improvements in EF Core, together with guidance and longer-term collaborations with other teams to improve end-to-end experiences that go beyond just EF.

Specific areas we plan to look at are:

Deployment, including the experience for using EF tooling such as for Migrations

Application models, including Xamarin and Blazor, and probably others

SQLite experiences, including the spatial experience and table rebuilds

AOT and linking experiences

Diagnostics integration, including perf counters

Performance

Lead developer: @roji

Tracked by issues labeled with area-perf in the 5.0 milestone

T-shirt size: L

Status: Scoped/Done

Scoping: Major performance improvements in the Npgsql provider are complete. Other performance work is now planned for EF Core 6.0.

For EF Core, we plan to improve our suite of performance benchmarks and make directed performance improvements to the runtime. In addition, we plan to complete the new ADO.NET batching API which was prototyped during the 3.0 release cycle. Also at the ADO.NET layer, we plan additional performance improvements to the Npgsql provider.

As part of this work we also plan to add ADO.NET/EF Core performance counters and other diagnostics as appropriate.

Architectural/contributor documentation

Lead documenter: @ajcvickers

Tracked by #1920

T-shirt size: L

Status: Cut

The idea here is to make it easier to understand what is going on in the internals of EF Core. This can be useful to anyone using EF Core, but the primary motivation is to make it easier for external people to:

Contribute to the EF Core code

Create database providers

Build other extensions

Update: Unfortunately, this plan was too ambitious. We still believe this is important, but unfortunately it won't land with EF Core 5.0.

Microsoft.Data.Sqlite documentation

Lead documenter: @bricelam

Tracked by #1675

T-shirt size: M

Status: Completed. The new documentation is live on the Microsoft docs site.

The EF Team also owns the Microsoft.Data.Sqlite ADO.NET provider. We plan to fully document this provider as part of the 5.0 release.

General documentation

Lead documenter: @ajcvickers

Tracked by issues in the docs repo in the 5.0 milestone

T-shirt size: L

Status: In-progress

We are already in the process of updating documentation for the 3.0 and 3.1 releases. We are also working on:

An overhaul of the getting started docs to make them more approachable/easier to follow

Reorganization of docs to make things easier to find and to add cross-references

Adding more details and clarifications to existing docs

Updating the samples and adding more examples

Fixing bugs

Tracked by issues labeled with type-bug in the 5.0 milestone

Developers: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

T-shirt size: L

Status: In-progress

At the time of writing, we have 135 bugs triaged to be fixed in the 5.0 release (with 62 already fixed), but there is significant overlap with the General query enhancements section above.

The incoming rate (issues that end up as work in a milestone) was about 23 issues per month over the course of the 3.0 release. Not all of these will need to be fixed in 5.0. As a rough estimate we plan to fix an additional 150 issues in the 5.0 time frame.

Small enhancements

Tracked by issues labeled with type-enhancement in the 5.0 milestone

Developers: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

T-shirt size: L

Status: Done

In addition to the bigger features outlined above, we also have many smaller improvements scheduled for 5.0 to fix "paper-cuts". Note that many of these enhancements are also covered by the more general themes outlined above.

Below-the-line

Tracked by issues labeled with consider-for-next-release

These are bug fixes and enhancements that are not currently scheduled for the 5.0 release, but we will look at as stretch goals depending on the progress made on the work above.

In addition, we always consider the most voted issues when planning. Cutting any of these issues from a release is always painful, but we do need a realistic plan for the resources we have.

Suggestions

Your feedback on planning is important. The best way to indicate the importance of an issue is to vote (thumbs-up) for that issue on GitHub. This data will then feed into the planning process for the next release.