Temporal tables are not supported for table splitting but no table splitting is used

[Leonvkampen]

Hi,

I am getting the following error on my ProjectTask entity.

Temporal tables are not supported for table splitting scenario. Table: 'ProjectTask'.

This is really weird because I generated a migration without any problems since this entity isn't using any table splitting.

Code is under here anyone that can help me with this?

public class ProjectTaskConfiguration : BaseAuditableEntityConfiguration<ProjectTask>
{
    public override void Configure(EntityTypeBuilder<ProjectTask> builder)
    {
        base.Configure(builder);

        builder.ToTable(nameof(ProjectTask), s => s.IsTemporal(x => x.UseHistoryTable("ProjectTaskHistory")));

        builder.HasKey(e => new { e.ProjectId, e.TaskTemplateId });

        builder.Property(e => e.Status)
            .HasConversion<string>();

        builder.HasMany(s => s.Answers)
            .WithOne(p => p.ProjectTask)
            .HasForeignKey(f => new { f.ProjectId, f.TaskTemplateId })
            .HasPrincipalKey(p => new { p.ProjectId, p.TaskTemplateId })
            .OnDelete(DeleteBehavior.Cascade);
    }
}

public class ProjectTask : BaseAuditableEntity
{
    public ProjectTask(Guid projectId, Guid taskTemplateId, ProjectStatus status)
    {
        ProjectId = projectId;
        TaskTemplateId = taskTemplateId;
        Status = status;

        Answers = new List<ProjectTaskAnswer>();
    }

    public Guid ProjectId { get; init; }
    public Guid TaskTemplateId { get; init; }

    public DateTime? TaskStarted { get; set; }
    public DateTime? TaskFinished { get; set; }

    public ProjectStatus Status { get; set; }

    public List<ProjectTaskAnswer>? Answers { get; set; }
    public Project? Project { get; init; }
}

[ajcvickers]

This issue is lacking enough information for us to be able to fully understand what is happening. Please attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.

[NaskoVasilev]

@ajcvickers I am getting the same problem in the this project: https://github.com/NaskoVasilev/Advanced-Concepts/tree/main/02_Temporal_Tables/TemporalTablesDemo

When I add owned entity to the employee model (https://github.com/NaskoVasilev/Advanced-Concepts/blob/main/02_Temporal_Tables/TemporalTablesDemo/TemporalTablesDemo/Data/Models/Employee.cs) and try to make a migration I get the following error: Temporal tables are not supported for table splitting scenario. Table: 'Employees'.

Does anyone have an idea how to cope with this problem? Removing owned entities is not a solution for me!

I cannot see what is the problem because the properties of the onwed entity are just regular columns in the database.
For example

class Person {
    public PersonName Name { get; set; }
}

class PersonName {
    public bool IsConfirmed { get; set; }

    public Lookup Salutation { get; set; }

    public String First { get; set; }

    public String Middle { get; set; }

    public String Last { get; set; }

    public Lookup Suffix { get; set; }

    public String UnparsedName { get; set; }
}

class ApplicationDbContext {
   protected override void OnModelCreating(ModelBuilder modelBuilder) {
       modelBuilder.Entity<Person>().OwnsOne(x => x.Name);
       modelBuilder.Entity<Person>().ToTable(x => x.IsTemporal());
   }
}

[ajcvickers]

@Leonvkampen @NaskoVasilev Owned entities make use of table splitting by default. This is supported in the EF7 previews. See #26469.

[ajcvickers]

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.