Using TPC it now does not cascade delete child objects

So I have a base class of Effort:

public abstract class Effort 
{
public int Id { get; private set; }
public ICollection<Signup>? Signups { get; set; }
// ...
}
public class EffortConfiguration : IEntityTypeConfiguration<Effort>
{
public void Configure(EntityTypeBuilder<Effort> builder)
{
builder.UseTpcMappingStrategy();
}
}

And it has 2 sub classes:

public class Job : Effort
{
// everything is in the base class
}
public class Event : Effort
{
public ICollection<Shift>? Shifts { get; set; }
// ...
}

And then we have the children (Signup & Shift):

public class Signup 
{
public int Id { get; private set; }
public Effort Effort { get; set; }
// ...
}
public class Shift : IPkIsId
{
public int Id { get; private set;  }
public Event Event { get; set; } = default!;
// ...
}

So when an Event is deleted, all of the Shift children are deleted. But when an Event or Job is deleted, the children Signup records are not deleted.

They are deleted if I don't call builder.UseTpcMappingStrategy().

I have tried fluent. In the SignupConfiguration I tried:

builder.HasOne(s => s.Effort)
.WithMany(e => e.Signups)
.OnDelete(DeleteBehavior.Cascade);

In the Event & JobConfiguration I tried (also tried it in Effort):

builder.HasMany(s => s.Signups)
.WithOne(e => (Job?)e.Effort)
.OnDelete(DeleteBehavior.Cascade);

Aside from this one problem TPC is working great. All my other unit tests pass. I get the two distinct tables.

I also tried moving public ICollection<Signup>? Signups { get; set; } to Event & Job, removing it from Effort. But that got an error during update-database where it said it was trying to create a duplicate function name.

What do I need to do here?

No, something like that won't work in TPC. The reason will be because of the way Keys work in TPC vs TPH/TPT

In TPH/T You will have one table for Effort that all subclasses share with an Effort.Id. In TPT you would have tables for Job and Event with Id columns, but those Id columns would match the Id column coming from Effort. For instance if you named the column EffortId, the Job and Event tables would have a PK of EffortId as well in a 1-to-1 relationship.

In TPC you have no Effort table to coordinate the PK so each subclass table will service its own Id PK. Any relationship from a Subclass to another common class like Signups can now not be based on the Effort subclass. From C# this is perfectly fine, but from a relational database it no longer is. Signup will want a FK back to a Job or Event, and a FK cannot point back to "one table or the other". In TPH/TPT the Signup.EffortId FK can go back to an Effort table, in TPC it has no single table to go back to.

For TPC you would need something like a JobSignup and EventSignup where the FK goes back to Job or Event respectively. This can be either separate tables with the same general Signup details, or you could use it as a many-to-many table between Job/Event and a single Signup table, but add a unique constraint to the SignupId in each of the joining tables to enforce that a Signup is only ever linked to one Job or Event. However, this just prevents a Signup being linked to two or more Jobs, or two or more Events, the database would still allow a Signup to be linked to one Job and one Event at the same time. You would need to enforce this at the application/domain level in code, and could have a maintenance job run periodically to look for Signups that are cross-referenced as a report for investigation and repair. Both Job and Event could have a collection of a Signup entity, but it couldn't be bi-directional. As far as EF is concerned it is a many-to-many relationship, it will just be treated as a one-to-one.

Using separate tables would negate this and while it does mean having two tables that are virtually identical, like the decision to use TPC to split storage and indexing for the subclasses rather than having everything in one table or across a joined two tables, splitting JobSignup from EventSignup still amounts to the same total # of records split between two tables instead of one with indexes for the FKs of their respective tables. (rather than searching/indexing across the entire combined set each time) It does mean that you wouldn't have a single Signup entity, but Job.Signups would be a collection of JobSignup while Event.Signups would be a collection of EventSignup. Technically these two Signup classes could still extend a base Signup, where the subclasses just manage the FK back to their respective Job/Event.