Narrow the feature gap between EF Core and EF6

[roji]

This is a grouping of related issues. Feel free to vote (👍) for this issue to indicate that this is an area that you think we should spend time on, but consider also voting for individual issues for things you consider especially important.

---

There are still some scenarios supported on EF6 which aren't on EF Core. In order to make it as easy as possible to transition from EF6 to EF Core, we plan to close this gap as much as possible, although some scenarios will remain unsupported by design.

Done in 6.0

• Query: Expand navigations after GroupBy operator is applied #22609
• Detect simple join tables in reverse engineering and create many-to-many relationships #22475
• Support ability to select top N of each group #13805
• Translate GroupBy followed by FirstOrDefault over group #12088
• Allow defining column order via [ColumnAttribute.Order] when creating tables #10059

Done in 7.0

• Allow applications to create model building conventions (aka public conventions) #214
• Support unidirectional many-to-many relationships #3864
• Attribute (Data Annotations) mapping for composite primary keys #11003
• Relational: TPC inheritance mapping pattern #3170
• Allow specifying different column names per table in TPT, TPC or entity splitting #19811
• Relational: Entity splitting support #620
• Map inserts, updates, and deletes (CUD operations) to stored procedures #245
• Interception for object materialization (a.k.a. "ObjectMaterialized") #15911
• Support raw SQL Queries for basic types like Guid, DateTime and int #11624
• Support for GroupBy entityType #17653
• Query: Support GroupBy when it is final operator #19929
• Query: Support GroupJoin when it is final query operator #19930
• Code templates for scaffolding entity types and DbContext from an existing database #4038

Done in 8.0

• Support raw SQL queries without defining an entity type for the result #10753
• Support lazy and explicit loading from entities queried with NoTracking behavior #10042
• Support querying over primitive collections #30426

Backlog

• Allow more flexible conditional mapping for TPH and similar #10140
• Update model from database #831
• Ability to refresh a context from the database #16491
• Navigation expansion improvements phase 2 #23206
• Turn-key Disconnected Entities Solution #5536
• Conventions should honor [MetadataType] #14544
• Set operations: allow operands with different entity types #16298
• FromSql: Support multiple resultsets #8127
• Allow proxy-creation to be temporarily disabled #12895
• Support using a single sproc per concrete type regardless of the inheritance mapping strategy #29143
• Allow to configure properties on non-collection complex types by using chaining in the lambda expression #31236
• GroupBy entity subquery #29013

[ankitmatrix08]

@AndriySvyryd May I know why this has been removed from 7.0.0 milestone as before it was on scheduled and confirmed here ?

[roji]

@ankitmatrix08 this has been changed to the "epics" milestone, which is where we track over-arching epics which track specific issues. It's just a "book-keeping" change - the concrete issues tracked here are still in the 7.0 milestone and are still planned (though that doesn't mean all will necessary make it in).

[ajcvickers]

@dotnet/efteam We need to discuss Epics again. When do we close them? If someone votes for an Epic, what are they voting for?

[roji]

I personally like to have epics in the milestone, allowing both ourselves and users to track work in the milestone for a high-level item. Here's how Npgsql does it - it's been very useful for me (and hopefully for users) to be able to drill down like this.

For work that's ongoing across multiple versions (e.g. EF6 parity), each milestone epic can simply reference the one before etc., and we can have one in the backlog for unplanned work.

But we should probably discuss in a design meeting...

[ankitmatrix08]

@ankitmatrix08 this has been changed to the "epics" milestone, which is where we track over-arching epics which track specific issues. It's just a "book-keeping" change - the concrete issues tracked here are still in the 7.0 milestone and are still planned (though that doesn't mean all will necessary make it in).

@roji That's the thing, since it's not clear as to what all items will make it to the 7.0.0 (among ef6-parity) release hence the confusion and trouble for us decide our migration.

[roji]

@ankitmatrix08 the milestone on each individual issue determines whether it's in the plan or not. This issue is just a list referencing those issues for easier tracking; we generally update it to keep it in sync, but that may not happen right away. Just check individual issues directly.

[mairaw]

I'm cleaning up the .NET 6 project. This shows as completed on the project dashboard but still open here. Not sure if this needs any updates.

[roji]

@mairaw thanks, we're using this to track overall EF6 parity issues across versions (6.0, 7.0, backlog...). Short of creating a separate issue for things we did in 6.0 and tracking that in the project, I think it makes sense to simply remove this.

[mairaw]

Sounds good @roji. Thanks for making the update.