Efcore: Add support for shadow property of IEnumerable<T> with custom conversion of T

Created on 6 May 2019  路  4Comments  路  Source: dotnet/efcore

Imagine the following:

public class ApplicationDbContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
}

public class Blog
{
    public Guid Id { get; set; }
    public IEnumerable<Post> Posts { get; set; }
}

public abstract class Post
{
    Guid Id { get; set; }

    public string PostType { get; set; }
}

public class ConcretePost : Post
{
    public string SomeData { get; set; }
}

I would like to have two tables: Blog and Post. The Post table should simply have 4 columns (Id, BlogId, PostType and Json) - so I want to tell EF to serialize (and deserialize) all Posts on the Blog entity but put it in a seperate table.

So far I have only been able to serialize the entire collection but I would like to serialize them individually.

Can this be achieved as of now or is it a missing feature?

area-c-mapping customer-reported needs-design type-enhancement

Most helpful comment

We discussed this in triage. It's quite a complicated mapping with several unusual elements. For example, Posts is exposed as a navigation property and Post should behave as an entity type, but the serialization is more like a collection of scalars...except that that collection should be in another table.

This is probably best thought of as an aggregate behavior (#1985) such that Posts is a collection of owned types. However, the storage of those owned types is complex and will probably require other features to be implemented first.

All 4 comments

@filleellif I don't believe that this is currently possible (without significant hacking.) It's partially covered by #2919 and #4021, and maybe also #1985.

Thank you @ajcvickers.

We discussed this in triage. It's quite a complicated mapping with several unusual elements. For example, Posts is exposed as a navigation property and Post should behave as an entity type, but the serialization is more like a collection of scalars...except that that collection should be in another table.

This is probably best thought of as an aggregate behavior (#1985) such that Posts is a collection of owned types. However, the storage of those owned types is complex and will probably require other features to be implemented first.

Thanks a lot for the response @ajcvickers! I figured it needed a lot of work to achieve this, and it's great to hear that you're considering it for the future.

For now, I've made some workarounds that satisfy my needs but I will follow this for sure!

Was this page helpful?
0 / 5 - 0 ratings