Is it possible to have different discriminators for the same entity type?

[search8]

Hello

I was wondering if it is possible to have different discriminators for the same entity type. What I mean by that is the following:

modelBuilder.Entity<AccountBE>(builder =>
{
   builder.ToTable("Account");
   builder.HasDiscriminator<string>("_accountType")
                 .HasValue<RootAccountBE>(AccountType.Test1.ToString())
                 .HasValue<RootAccountBE>(AccountType.Test2.ToString())
                 .HasValue<ChildAccountBE>(AccountType.Test3.ToString());
}

So I have the two entities (RootAccountBE and ChildAccountBE) which both derive from AccountBE. I have two different Root Account types which have the same properties but are of a different type. So I have specified it as outlined above. It seems though that the discriminator configured last wins.

So when I query an account:

db.Set<T>().FindAsync(id)

For Account Type Test1 I get null, for Account Type Test2 I get a result. If I switch the configuration around (put Type Test2 before Test1) the result is opposite. Is there any way to specify that in a different way or do I have to create an individual class per type?

Thanks,
Serge

[smitpatel]

I have two different Root Account types which have the same properties but are of a different type.

Can you elaborate what do you mean by different types? Because there is only 1 CLR type RootAccountBE.

[search8]

I meant from business side of things they are different but are made up of the same properties that's why I haven't created their own type. What I'm trying to achieve is something like this I guess:

.HasValue<RootAccountBE>(AccountType.Test1.ToString() || AccountType.Test2.ToString())

[smitpatel]

How do you plan to interpret the correct type? Suppose you are given object of CLR type RootAccountBE how would you find out which type it would map to on business side?

[search8]

My RootAccount has an enum property AccountType which is also the discriminator:

public class RootAccountBE : AccountBE
{
        public override AccountType AccountType { get: set: }
}

I mean I can totally create their own types. Maybe that's the better choice in the long run anyways (usually turns out that way). I was just wondering if there is an option to do that or if I'm missing something here.

[ajcvickers]

@search8 We don't plan to add built in support for this, but #10140 is a more general issue that covers allowing more flexible conditional mapping, which should allow this. So closing as a narrower duplicate of that issue.