alvinashcraft
shared this story
from 
.NET Blog.
Now that Entity Framework Core (EF Core) 1.0 is released, our team is beginning work on bug fixes and new features for the 1.1 release. Keep in mind that it’s early days for this release, we’re sharing our plans in order to be open, but there is a high chance things will evolve as we go.
High level goals
Our goal with 1.1 release is to make progress on the items that are blocking folks from using EF Core.
Fix a lot of the bugs reported on the 1.0 release in order to improve stability
Tackle a number of critical O/RM features that are currently not implemented in EF Core
Timeframe
EF Core 1.1 is scheduled for Q4 2016 / Q1 2017. We’ll have a more exact date as we get closer to the release and decide where to draw the line on features to be included.
What features are we working on
Over the next couple of months we are beginning work on a number of features. Some we expect to include in 1.1, others we expect to deliver in a future release.
Features we expect to ship in 1.1
Following is the list of features that our team is expecting to include in the 1.1 release.
LINQ improvements
Improved translation to enable more queries to successfully execute, with more logic being evaluated in the database (rather than in-memory).
Queries for non-model types allows a raw SQL query to be used to populate types that are not part of the model (typically for denormalized view-model data).
DbSet.Find provides an easy way to fetch an entity based on its primary key value.
Explicit Loading allows you to trigger population of a navigation property on an entity that was previously loaded from the database.
Additional EntityEntry APIs from EF6.x such as Reload, GetModifiedProperties, GetDatabaseValues etc.
Connection resiliency automatically retries failed database commands. This is especially useful when connection to SQL Azure, where transient failures are common.
Pluralization support for reverse engineering will result in singularized type names and pluralized DbSet property names, regardless of whether the table name is singular or plural.
Stable release of tools – whilst the runtime has reached RTM, the tooling for EF Core (plus .NET Core and ASP.NET Core) is still pre-release.
Other features we’re starting on
We’re also planning to start work on the following features, but do not expect them to be ready in time for inclusion in the 1.1 release. These features will require a longer time to implement, stabilize, and gather feedback from the community and therefore they will have a longer pre-release cycle.
Complex/value types are types that do not have a primary key and are used to represent a set of properties on an entity type.
Simple type conversions such as string => xml.
Visual Studio wizard for reverse engineering a model from an existing database.
Will EF Core replace EF6.x after the 1.1 release
The short answer is no. EF6.x is still the mature, stable data access stack and will continue to be the right choice for many applications when EF Core 1.1 is available. Along with EF Core 1.1, we are also starting work on the EF6.2 release – we’ll share our plans on that shortly. That said, EF Core will be a viable choice for more applications once 1.1 is released. Our documentation has guidance on choosing between EF6.x and EF Core, and this same guidance will apply when 1.1 is released.
Notable exclusions
The full backlog of features that we want to add to EF Core is too long to list here, but we wanted to call out a few features that we know are critical to a lot of applications and will not be worked on in the 1.1 timeframe. This is purely a matter of not being able to work on every feature at the same time, and the order in which things must be implemented. As an example, Lazy Loading will build on top of some of the feature work we are doing in the 1.1 timeframe (such as Explicit Loading).
While we realize this list will cause frustration for some folks, we want to be as transparent as possible so that you all have the information required to make an informed decision about when EF Core would be the right choice for you.
Many-to-many relationships without join entity. You can already model a many-to-many relationship with a join entity, see Relationships for details.
Alternate inheritance mapping patterns for relational databases, such as table per type (TPT) and table per concrete type (TPC). Table per hierarchy (TPH) is already supported.
Lazy loading enables navigation properties to be automatically populated from the database when they are accessed. Some of the features we implement in 1.1 may enable rolling your own lazy loading, but it will not be a first class feature in 1.1.
Simple command interception provides an easy way to read/write commands before/after they are sent to the database.
Stored procedure mapping allows EF to use stored procedures to persist changes to the database (FromSql already provides good support for using a stored procedure to query, see Raw SQL Queries for details).
Spatial data types such as SQL Server’s geography & geometry. The type conversion work we are starting may enable some spatial scenarios, but it will not be a complete solution.
Seed data allows you to easily specify a set of data to be present in the database. This is useful for populating lookup tables etc. and for inserting test data.
GROUP BY translation will move translation of the LINQ GroupBy operator to the database when used with an aggregate function (i.e. when all underlying rows do not need to be returned to the client).
Update model from database allows a model that was previously reverse engineered from the database to be refreshed with changes made to the schema.
Model visualization allows you to see a graphical representation of your model.
