As mentioned in the announcement of the .NET Core 2.1 roadmap earlier today, at this point we know the overall shape of our next release and we have decided on a general schedule for it. As we approach the release of our first preview later this month, we also wanted to expand on what we have planned for Entity Framework Core 2.1.
New features
Although EF Core 2.1 is a minor release that builds over the foundational 2.0, it introduces significant new capabilities:
- Lazy loading: EF Core now contains the necessary building blocks for anyone to write entity classes that can load their navigation properties on demand. We have also created a new package, Microsoft.EntityFrameworkCore.Proxies, that leverages those building blocks to produce lazy loading proxy classes based on minimally modified entity classes. In order to use these lazy loading proxies, you only need navigation properties in your entities to be virtual.
- Parameters in entity constructors: as one of the required building blocks for lazy loading, we enabled the creation of entities that take parameters in their constructor. You can use parameters to inject property values, lazy loading delegates, and services.
- Value conversions: Until now, EF Core could only map properties of types natively supported by the underlying database provider. Values were copied back and forth between columns and properties without any transformation. Starting with EF Core 2.1, value conversions can be applied to transform the values obtained from columns before they are applied to properties, and vice versa. We have a number of conversions that can be applied by convention as necessary, as well as an explicit configuration API that allows registering delegates for the conversions between columns and properties. Some of the application of this feature are:
- Storing enums as strings
- Mapping unsigned integers with SQL Server
- Transparent encryption and decryption of property values
- LINQ GroupBy translation: Before EF Core 2.1, the GroupBy LINQ operator would always be evaluated in memory. We now support translating it to the SQL GROUP BY clause in most common cases.
- Data Seeding: With the new release it will be possible to provide initial data to populate a database. Unlike in EF6, in EF Core, seeding data is associated to an entity type as part of the model configuration. Then EF Core migrations can automatically compute what insert, update or delete operations need to be applied when upgrading the database to a new version of the model.
- Query types: An EF Core model can now include query types. Unlike entity types, query types do not have keys defined on them and cannot be inserted, deleted or updated (i.e. they are read-only), but they can be returned directly by queries. Some of the usage scenarios for query types are:
- Mapping to views without primary keys
- Mapping to tables without primary keys
- Mapping to queries defined in the model
- Serving as the return type for FromSql() queries
- Include for derived types: It will be now possible to specify navigation properties only defined in derived types when writing expressions for the Include() methods. The syntax looks like this:
var query = context.People.Include(p => ((Student)p).School); - System.Transactions support: We have added the ability to work with System.Transactions features such as TransactionScope. This will work on both .NET Framework and .NET Core when using database providers that support it.
Other improvements and new initiatives
Besides the major new features included in 2.1, we have made numerous smaller improvements and we have fixed more than a hundred product bugs. We also made progress on the following areas:
- Optimization of correlated subqueries: We have improved our query translation to avoid executing N + 1 SQL queries in many common scenarios in which a root query is joined with a correlated subquery.
- Column ordering in migrations: Based on customer feedback, we have updated migrations to initially generate columns for tables in the same order as properties are declared in classes.
- Cosmos DB provider preview: We have been developing an EF Core provider for the DocumentDB API in Cosmos DB. This is the first document database provider we have produced, and the learnings from this exercise are going to inform improvements in the design of the subsequent release after 2.1. The current plan is to publish an early preview of the Cosmos DB provider in the 2.1 timeframe.
- Sample Oracle provider for EF Core: We have produced a sample EF Core provider for Oracle databases. The purpose of the project is not to produce an EF Core provider owned by Microsoft, but to:
- Help us identify gaps in EF Core’s relational and base functionality which we need to address in order to better support Oracle.
- Help jumpstart the development of other Oracle providers for EF Core either by Oracle or third parties.
Note that currently our sample is based on the latest available ADO.NET provider from Oracle, which only supports .NET Framework. As soon as an ADO.NET provider for .NET Core is made available, we will consider updating the sample to use it.
What’s next
We will be releasing the first preview of EF Core 2.1, including all the features mentioned above, later this month. After that, we intend to release additional previews monthly, and a final release in the first half of 2018.
A big thank you to everyone that uses EF Core, and to everyone who has helped make the 2.1 release better by providing feedback, reporting bugs, and contributing code.
Thank you for the update, but what about Spatial Data Types (DbGeography, SqlGeography) ?!
this feature was requested more than 3 years ago:
https://github.com/aspnet/EntityFrameworkCore/issues/1100
And people still requesting/commenting but still no confirmation !!
@Ikourfaln, we have tried to be explicit about spatial support not being part of 2.1. That is why that issue is in the backlog milestone. See also https://github.com/aspnet/EntityFrameworkCore/issues/1100#issuecomment-339381788. This is the most recent update on how we are thinking we are going to tackle spatial support. We will consider it for the next release after 2.1.
@Diego
Thank you for the reply, but I’m confused, some people from your team, such as this:
https://github.com/aspnet/EntityFrameworkCore/issues/1100#issuecomment-338292540
Said that it will works if you target Full .NET Framework, is that true? is yes, I wish if you can share with us more details.
Thank you.
@Ikourfaln what that comment says is still true for 2.1: If you are using SQL Server and running on .NET Framework, you will be able to have properties of type SqlGeography and SqlGeometry, and you should be able to use FromSql() to call spatial functions (this was possible before) and return results that contain those types (this is new in 2.1).
We enabled this as part of an overhaul of our type mapping logic that we had to do for value conversions.
However this is very limited and we don’t consider it enough to claim that we support spatial in 2.1. That is why issue #1100 remains open.
@Diego
Thank you again, for .NET Framework app, we can use SqlGeography instead of DbGeography and use Query types with FromSql to get the desired results.
it will be great if you can share some examples in docs so at least we know that we have a solution and we are not 100% blocked.
Thank you.
Thanks for the improvements. Is there documentation somewhere that describes how to use the new features such as value conversions? Also, is lazy loading enabled by default for collections that are virtual, or, do you need to set a property on the context? If I remember correctly, the plan was to make lazy loading off by default.
@Jon Miller3, we don’t have any documentation yet. We will have some code snippets when we release the preview.
The main API will be HasConversion() when you are configuring a property on OnModelCreating. There are several overloads of it. In the meanwhile I will try to find you a good test you can look at in our code.
For lazy loading, you have to add the proxies package plus chain the UseLazyLoadingProxies method on OnConfiguring. At that point if we cannot create lazy loading proxies (e.g. because navigation properties are not virtual), we throw an exception.
Just to let you know. A large part of the documentation for the 2.1 features is now available. This is a good place to start: https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-2.1.
Is there a way to generated pre-compiled views to ease first query execution times in EF core 2? In EF6 there were power tools and T4 templates that could be used to generate views off of DBContext classes. I’m looking for similar in ef core 2 , because on large databases performance of that initial load is severely slow,….
Jonathan,
EF Core’s mapping engine is simpler and does not require anything similar to what in previous versions of EF was known as view generation (at least until now). But depending on the size of the model (e.g. number of entities and relationships) you may be impacted by the initial cost of figuring out all the model based on reflecting on the CLR entity types and the fluent calls on the model builder.
We have the idea in our backlog to allow front-loading this cost so that it doesn’t need to happen on startup: we call it compiled models and is tracked at https://github.com/aspnet/EntityFrameworkCore/issues/1906. However in the shorter term we may be able to optimize the performance of model building for specific patterns by looking at profiles and figuring out ways to eliminate redundant work. If you have a model that you can share with us and that you are seeing performs very badly with our latest version (at the time of this writing, EF Core 2.1 Preview 2 is available) then please create an issue at https://github.com/aspnet/EntityFrameworkCore/issues/1906 and include a repro with the whole model.
Will 2.1 automatically handle detached child entities that have primary keys but may or may not exist in the database, i.e. if they exist update them, otherwise add them, or will we still have to process the adds/updates ourselves?
John, The Update method on EF Core handles this for simple cases with auto-generate keys. See https://docs.microsoft.com/en-us/ef/core/saving/disconnected-entities#mix-of-new-and-existing-entities. Scenarios that require customizing the logic to decide if an entity instance represents a new or an existing entity can be handled with the TrackGraph method: https://docs.microsoft.com/en-us/ef/core/saving/disconnected-entities#trackgraph.
John,
The Update method on EF Core handles this for simple cases with auto-generate keys. See https://docs.microsoft.com/en-us/ef/core/saving/disconnected-entities#mix-of-new-and-existing-entities. Scenarios that require customizing the logic to decide if an entity instance represents a new or an existing entity can be handled with the TrackGraph method: https://docs.microsoft.com/en-us/ef/core/saving/disconnected-entities#trackgraph.
(The content was deleted per user request)
Stored Procedure support in EF. Would we wait for it? Long missing…
Agreed….Microsoft’s assumption that no one is still using sprocs,…. or Asp.Net Membership or any stable technology that organizations have large amounts of code in….
I’m currently using StoredProcedureEFCore and it works well … https://github.com/verdie-g/StoredProcedureEFCore