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?
@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!
Most helpful comment
We discussed this in triage. It's quite a complicated mapping with several unusual elements. For example,
Postsis exposed as a navigation property andPostshould 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
Postsis a collection of owned types. However, the storage of those owned types is complex and will probably require other features to be implemented first.