Q: How to cascade deletes when DB-first FK is the wrong way around?

[bert2]

I'm currently working with a legacy DB where a one-to-one relation has been modeled the wrong way around; i.e. the foreign key column is stored on the entity which should be the principal entity of the relation. Consequently, EF is refusing to cascade-delete the should-be dependent entity of the relation.

TL;DR

Is there a way to specify the principal entity of a one-to-one relation independently of where the FK is stored?

Detailed explanation

Consider this model of a very similar schema:

Here a Post has a collection of PositiveReviews which each have a PraiseText (yes, I know, it's a stupid example, but I hope it gets my point across). As you can see the FK of the relation PositiveReview-PraiseText is stored on PositiveReview, effectively making PraiseText the principal entity of the relation. This means whenever a PositiveReview gets deleted from a Post, then the corresponding PraiseText will not be deleted and remains orphaned in the DB.

How can I convince EF to cascade-delete those PraiseTexts?

Steps to reproduce

I created a test project with integration tests that you can use to reproduce the issue:

> git clone https://github.com/bert2/ef-vs-garbage-db.git
> cd .\ef-vs-garbage-db\
> dotnet test

The test DeletesTextWhenDeletingReview will fail.

Further details

EF Core version: 2.2.1
Database Provider: Microsoft.EntityFrameworkCore.Sqlite
Stackoverflow question: EF Core: How to cascade delete when DB-first FK is the wrong way around?

[ajcvickers]

@bert2 This is probably best handled by logic in an overridden SaveChanges method. For example:

public override int SaveChanges(bool acceptAllChangesOnSuccess)
{
    // Note that this is internal code to force cascade deletes to happen.
    // It may stop working in any future release.
    ChangeTracker.DetectChanges();
    this.GetService<IStateManager>().GetEntriesToSave();

    try
    {
        ChangeTracker.AutoDetectChangesEnabled = false;

        foreach (var entry in ChangeTracker
            .Entries<CritiqueText>()
            .Where(e => Entry(e.Entity.Review).State == EntityState.Deleted))
        {
            entry.State = EntityState.Deleted;
        }
    }
    finally
    {
        ChangeTracker.AutoDetectChangesEnabled = true;
    }

    return base.SaveChanges(acceptAllChangesOnSuccess);
}

Some notes about this code:

• It requires that the CritiqueText entities are loaded
• The Review instances are themselves getting deleted through the cascade delete mechanism, and this mechanism doesn't kick-in until SaveChanges runs. This means the Review entities are not yet marked as Deleted when SaveChanges starts. This is controllable in 3.0--see Allow cascade delete timing to be configured #14470. For now I have included a little bit of internal code that will trigger the cascade mechanism.
• Auto DetectChanges is disabled for rest of the processing, since we know we're working with fresh information from the first call.

[bert2]

Nice, this worked perfectly. Thanks for the quick answer!

I refactored the solution to be based on attributes. Interested parties can find it in the test project repo.

[voroninp]

Unfortunately, it looks more like a hack rather than a robust solution. Moreover, if you have plans to allow configuring shapes of aggregates, you'll probably need to implement deletion of an aggregate as well irrespective of db's dependency direction.