2

Take the following entities:

public sealed class Employee
{
    private Supervisor supervisor;

    public long Id { get; set; }

    public long? SupervisorId { get; set; }

    public Supervisor Supervisor
    {
        get => this.Department?.Supervisor ?? this.supervisor;
        set => this.supervisor = value;
    }

    public long? DepartmentId { get; set; }
    public Department Department { get; set; }
}

public sealed class Department
{
    public long Id { get; set; }

    public long? SupervisorId { get; set; }
    public Supervisor Supervisor { get; set;}
}

And the following DbContext:

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions options)
        : base(options)
    {
    }

    public DbSet<Employee> Employee { get; set; }
    public DbSet<Supervisor> Supervisor { get; set; }
    public DbSet<Department> Department { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Entity<Employee>()
            .Property(e => e.Supervisor)
            .HasField("supervisor")
            .UsePropertyAccessMode(PropertyAccessMode.Field);
    }
}

When running the update database command:

dotnet tool run dotnet-ef database update

The following error is generated:

The property 'Employee.Supervisor' is of type 'Supervisor' which is not supported by current database provider. Either change the property CLR type or ignore the property using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.

How do I combine both the backing field concept and the navigation property concept? My goal is to allow the application to access employee.Supervisor and determine their supervisor if they have a direct report, or if they belong to a department use the department's supervisor instead.

I know I can add a new property to Employee named ComputedSupervisor with this logic, but I am trying to avoid having to refactor a bunch of code.

Thanks for any tips in advance!

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
  • I am pasting a link that I believe might help you out, give it a try https://stackoverflow.com/questions/55977692/the-property-x-is-of-type-y-which-is-not-supported-by-current-database-provider. If either the link was helpful or not keep me posted. – vasilisdmr Mar 10 '20 at 15:03
  • Hey @vasilisdmr! Unfortunately, the link you posted does not help. The issue in this case is related to the fact that it is a navigation property with a backing field. Thank you for trying! – Anthony Iacono Mar 10 '20 at 16:12
  • What EF Core version are you targeting? – Ivan Stoev Mar 10 '20 at 17:56
  • @IvanStoev EF Core 3.1.2 – Anthony Iacono Mar 10 '20 at 18:21
  • Then it should use the backing field by default. Simply remove the (invalid `Property`) fluent configuration. See https://stackoverflow.com/questions/60617430/efcore-3-readonly-access-to-private-navigation-field/60618772#60618772 – Ivan Stoev Mar 10 '20 at 18:23
  • @IvanStoev I think you are the winner man! If you make an actual answer, I can mark it as accepted. Thank you! – Anthony Iacono Mar 10 '20 at 18:24
  • To add the that, your link was perfect since it shows me how to use a different naming convention all together (which is why I was using the fluent API) – Anthony Iacono Mar 10 '20 at 18:26
  • I can't my friend, because it would be a duplicate. But if you don't mind, we can mark your question as duplicate. What about the link, it is something I've answered today, so it was easy to find :-) – Ivan Stoev Mar 10 '20 at 18:26
  • I don't think this is actually a true duplicate. In other words, while the solution is basically the same, I am not enforcing that my property is truly readonly. – Anthony Iacono Mar 10 '20 at 18:28
  • Now it is. Cheers and happy coding. – Ivan Stoev Mar 10 '20 at 18:35

0 Answers0