Efcore: Support inheritance for owned types

[ajcvickers]

For example, this from #9536:

```C#
public class Friend
{
public int Id { get; set; }
public string Name { get; set; }

public FullAddress Address { get; set; }

}

public class LessThanFriend
{
public int Id { get; set; }
public string Name { get; set; }

public CityAddress Address { get; set; }

}

public class CityAddress
{
public string Cap { get; set; }
public string City { get; set; }
}

public class FullAddress : CityAddress
{
public string Street { get; set; }
}

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity().OwnsOne(e => e.Address);
modelBuilder.Entity().OwnsOne(e => e.Address);
}
```
This is ambiguous as to whether LessThanFriend.CityAddress should be mapped to allow inheritance such that either a CityAddress or a FullAddress could be persisted. Typically, we only map inheritance when both types are in the model. However, having both types in the model as Owned types on different entities perhaps does not have the same semantics--especially when thinking of them like complex types.

Based on triage discussion from #9536, we think we want to support both the simple mapping (just persisting given concrete type, which is what the request on #9536 is for) and the inheritance mapping, which would require, for TPH, and additional discriminator column in the table. We did not come to a final decision on which should be the default, or what the new API will look like to switch between the two.

[AndriySvyryd]

We would need API on ReferenceOwnershipBuilder to declare the derived types.
Related to https://github.com/dotnet/efcore/issues/10140

[andre-f-paggi]

It took me so much time to get to this issue.

I am having a problem in which a owned type generates a Discriminator property, even though there is no need for it, since the class that has this property is not derived anywhere else.

Can this be the same issue?

I tried removing it from migration and from the snapshot to test, but it generates a wrong sql statement when acessing the DbContext on that Set.

Is there any way to get around this, without generating the property on the database?

[ajcvickers]

@andre-f-paggi Please file a new issue and include a runnable project/solution or complete code listing that demonstrates the behavior you are seeing.

[chris-stormideas]

@ajcvickers I can look at supplying a runnable solution if it will assist getting it resolved quicker

[ajcvickers]

@chris-stormideas We understand what this issue is about--i.e. inheritance mapping into a shared table is not supported. The feature is currently on the backlog, and not considered very high priority. The best way to influence getting it resolved is probably to make a case for why this specific mapping is so important.

[davidroth]

@ajcvickers

What about collections of owned types, where the owned-collection is polymorphic?
For example:

public class Order
{
    public List<Position> Positions { get; set; } // Owned collection
}

public abstract class Position
{ }

public class FancyPosition : Position
{ }

public class StandardPosition : Position
{ }

public class SampleContext : DbContext
{
    public virtual DbSet<Order> Orders { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        modelBuilder.Entity<Order>().OwnsMany(p => p.Positions);
    }
}

Is this implicitly tracked by this issue or would you recommend creating a new issue for this?

[ajcvickers]

@AndriySvyryd Thoughts on polymorphic owned collections?

[AndriySvyryd]

Polymorphic owned collections will be covered by this, but similar to non-collections all derived types will need to be configured explicitly.

[digitalpowers]

Polymorphic owned collections do provide the ability to compose our object model which is really quite nice.
From my perspective having to define all the derived types explicitly isn't a problem at all.
Do you guys have an idea when this issue might bubble up in the backlog?

I have a project I have been waiting to migrate over to efcore that currently uses Horrible InHouse Awful ORM (tm) that I wrote years ago much to today me's regret. This is the only feature left that I cant really support with efcore.

[AndriySvyryd]

@digitalpowers For now we can only say that it won't happen this year.

[davidroth]

Thanks for the feedback. If polymorphic owned collections are covered by this issue, I would recommend updating the issue title+description so that users can find this. ATM it is not really clear and looks like it only covers inline owned types. Thanks!

[Lobosque]

@AndriySvyryd Does this issue also cover the case where I explicitly want to set a HasDiscriminator under an owned entity?

Example:

            builder.OwnsOne<AlertPattern>("Pattern", b =>
            {
                b.HasDiscriminator<int>("type")
                    .HasValue<PatternOne>(1)
                    .HasValue<PatternTwo>(2)
                    .HasValue<PatternThree>(3)
                    .HasValue<PatternFour>(4)
                    .HasValue<PatternFive>(5);
            });

In this particular example, AlertPattern is an abstract class and PatternOne and friends inherit it.

[AndriySvyryd]

@Lobosque Yes

[drdamour]

this would be awesome when using Cosmos NoSQL as one of it's advertised selling points is that embedded documents don't have to follow a specific structure/single type. as it is now i have to do weird things like serialize the collection as json with $type magic which feels very dirty