Allow temporal table history table name to be excluded from generation

[IanKemp]

Note: this entire post is written wearing Microsoft SQL Server-coloured glasses, given it's currently the only DBMS with an EF Core implementation for temporal tables.

Currently, when generating an entity for a temporal table, EFPT explicitly generates its history table name into the DbContext:

modelBuilder.Entity<MyEntity>(entity =>
{
    entity.ToTable(tb => tb.IsTemporal(ttb =>
            {
                ttb.UseHistoryTable("MyEntity_History", "dbo");
                ttb
                    .HasPeriodStart("PeriodStart")
                    .HasColumnName("PeriodStart");
                ttb
                    .HasPeriodEnd("PeriodEnd")
                    .HasColumnName("PeriodEnd");
            }));

            ... other configuration...
});

This becomes problematic if you need to change the history table's name: this should be a pure SQL DDL operation involving unversioning the temporal table, renaming its now-unlinked history table, then reversioning the temporal table with its renamed history table.

But because of the fact that EFPT explicitly emits the history table name at the time of generation into the DbContext, this means that any code using that DbContext must also be regenerated and recompiled and redeployed when the history table is renamed. This adds a lot of overhead (especially, coordination around simultaneous DB and code releases) for what should be a simple, database-only operation.

And... explicitly emitting the temporal table name isn't even necessary anyway, because the database implicitly knows what that table is via for system_time! As such I am not even sure why the UseHistoryTable method exists...

Ideally then, it would be most useful if EFPT had a UI option to allow us to disable emitting the UseHistoryTable() call.

[ErikEJ]

What happens if you rename the underlying table and make no code changes?

[IanKemp]

What happens if you rename the underlying table and make no code changes?

...

The code still works just fine.

I am not a smart man.

Sorry for the bother.

[ErikEJ]

@IanKemp no worries, your feedback is always appreciated.