Relational: Entity splitting support

[divega]

This work item represents the mapping capability to slice the data contained by an object into multiple tables.

Limitations:

• Properties mapped to multiple columns can't use store-generated values
• Foreign keys and indexes split across tables won't be created in the database

Related: #17270 (comment)

[ilmax]

I would love if this feature does not fill in the standard Relational library but perhaps is exposed as a additional feature (pay for play scenario) which I can plug in only if needed

[AndriySvyryd]

Related to TPT #2266

[ajcvickers]

Note: consider optional relationships: #9773

[AndriySvyryd]

• Model building
  • Column name overrides
  • Runtime model
  • Compiled model
  • Relational model
• Migrations
  • Snapshot
  • Seeding
• Update
• Query
• Tests
  • Non-PK columns duplicated across tables
  • Concurrency tokens
  • Customizing linking FK (By default it's required dependent)
  • Views
  • With triggers and owned types
  • With table splitting

API proposal:

modelBuilder.Entity<Customer>().SplitToTable("CustomerDetails", tb =>
{
    // PK mapped to all tables by default

    // Any other property mapped to a split table is not mapped to the default table
    tb.Property(c => c.AlternateKey);

	// Empty column name effectively removes the property from the mapping fragment
    tb.Property(c => c.AlternateKey).HasColumnName("");
});

modelBuilder.Entity<Customer>().ToTable("Customer", tb =>
{
    // Properties can be explicitly mapped to the default table too
    tb.Property(c => c.AlternateKey);
});

modelBuilder.Entity<Customer>().SplitToView("CustomerView", tb =>
{
    tb.Property(c => c.AlternateKey);
});

[netspark]

Would be very appreciated for implementing this, we have a lot of legacy one-to-one tables in DB which make no sense to treat separately in backend

[jansomers]

Would very much love this feature, also the optional relationships is a must have when implementing entity splitting

[maurei]

Any update? Would love to see this feature incorporated.

[ajcvickers]

@maurei This issue is in the Backlog milestone. This means that it is not going to happen for the 3.0 release. We will re-assess the backlog following the 3.0 release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[GeorgeTsaplin]

I suppose what Owned Entity Types can be used as an alternative for Entity Splitting and it's already implemented at EFCore 2.0.

[artsiomtserashkovich]

Hi. Do you have any update?

[ajcvickers]

@ArtemTereshkovich This issue is in the Backlog milestone. This means that it is not going to happen for the 3.0 release. We will re-assess the backlog following the 3.0 release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[mister-conor]

This feature is a must for people migrating legacy systems to EF.

[leus]

Yes please - consider the scenario where a table is split for patitionin causes (for example, to separate LOB and row data).

[bairog]

Lacking this feature in EF Core stops me (like other people) from migrating legacy projects from EF 6.4.
@ajcvickers Do you have any concrete plan/schedule? What does "considered-for-net-release" label mean? .NET 5 (scheduled in November 2020) or .NET Core 3.x (may happend earlier)?

[AndriySvyryd]

@bairog We'll consider adding it to EF Core 5 if there's enough time left, otherwise it will likely go into EF Core 7

[bairog]

Hello. Do you have any updates? Is it going to be included to EF Core 5 release?

[roji]

@bairog no, this feature did not make it into the upcoming 5 release. We'll consider this again for the 6.0 planning

[bairog]

Hello.
Are you planning to implement this in EF Core 6.0? It is vital for EF6 feature parity.
No single word about it in this devblogs announcement

[ajcvickers]

@bairog This is a stretch goal for EF Core 6.0, as indicated by consider-for-current-release label. This means we may get to it for 6.0 if we have time in the schedule, but you shouldn't count on it.

[bairog]

So it looks like even EFCore 6.0 LTS most likely will not have the entire list of current EF 6.4 features. Very disappointing to hear :(

[bairog]

EF Core 6 Preview 1 is out - no word about Entity Splitting.
We've succesfully migrated most of our projects from EF 6.4.4 + Devart.Data.SQLite.EF6 provider (commercial) to EF Core 5 + Microsoft.EntityFrameworkCore.SQLite provider (free). Only one project cannot be ported because it uses Entity Splitting. Still hoping for EF Core 6 release..

[bairog]

Hello again.
Does this definitely planned to be implemented in EF Core 7?
We've succesfully migrated most of our projects from EF 6.4.4 + Devart.Data.SQLite.EF6 provider (commercial) to EF Core 6 + Microsoft.EntityFrameworkCore.SQLite provider (free). Only one project cannot be ported because it uses Entity Splitting.

[ajcvickers]

@bairog While nothing in lifesoftware is ever certain, I'm very confident that this will not be punted and will be included in EF7.

[DM2489]

I've been following this thread since EF Core 1.0.

We've also got a couple of apps that we've been forced to update to .NET Core (due to various other dependencies), and that have lost entity splitting capabilities.

We've had to come up with some weird, whacky, and nasty 'workarounds' to get over the lack of the entity splitting feature, such as combining multiple database tables into one, causing data to be replicated, etc.

I'd love to finally get my hands on this feature and tidy up these projects/databases to how they should be. I love .NET Core and EF Core but this single feature is the biggest thorn in my entire software stack at the moment - lack of entity splitting makes me feel as though I am intentionally developing antipattern applications, and there's not much I can really do about it without this feature 😨

[OskarKlintrot]

Can I somehow specify that the foreign key is already specified in a table? Right now, EF tells me that I must have the FK in the "main" table but the limitation in the issue descriptions only says that FK won't be created in the database. In my case it's already created, is it still not possible to have the FK in another table?

[ajcvickers]

@OskarKlintrot Please open a new issue and attach a small, runnable project or post a small, runnable code listing that shows what you are attempting and what doesn't work.