Support IDictionary navigation property for one-to-many relationship
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reproducing the model-building exception with the Parent.Children Dictionary and compare it with the ICollection navigation behavior described in the issue. Investigate EF Core's navigation and relationship metadata, then verify that dictionary keys, migrations, querying, and change tracking behave as intended.
Written by the indexing model from the issue text.
Description
My model uses field Children being (subtype of) IDictionary<child_key, Child> to express one-to-many relationship Parent-Child and supporting easy/fast access to children items.
I would like EF Core to support this pattern in similar way ICollection<Child> Children is handled.
Consider
class Child {
public long id { get; set; }
public string Text { get; set; }
}
class Parent {
public long id { get; set; }
public string name { get; set; }
public System.Collections.Generic.Dictionary<long, Child> Children { get; set; }
}
this throws exception
Unhandled exception. System.InvalidOperationException: The property 'Parent.Children' is of type 'Dictionary<long, Child>' which is not supported by current database provid
er. Either change the property CLR type or ignore the property using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.
and adding conversion specification like this:
modelBuilder.Entity<Parent>()
.Property(m => m.Children)
.HasConversion(v => v.Values, v => v.ToDictionary(f => f.id, f => f));
doesn't help either.
I also found this question asking for similar feature with a number of hack solutions (https://stackoverflow.com/questions/60726966/ef-core-use-a-dictionary-property), none of them is really addressing the problem though.
When the property is (sub)type of ICollection<Child>, then it's treated as navigational property, with migrations it creates ParentId property in Child table, etc. With IDictionary and appropriate information about keys it could work in similar way and even keep better performance for some tracking operations.
- Dominant language
- C#
- Stars
- 14.8k
- Forks
- 3.4k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 134
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dotnet/efcore
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
customer-reported
Difficulty 5/5 Over a week Newbie friendliness 38/100
-
area-cosmos area-vector-search
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
area-cosmos
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
area-tools needs-design
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
:watch: Not Triaged 11.0 fundamentals/subsvc
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
dotnet/AspNetCore.Docs#37699 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SubtitleEdit/subtitleedit#15108 · 1 comment ·
-
area/docs-content Bug pulumi/docs
Difficulty 1/5 1-3 hours Newbie friendliness 94/100
-
agentic-workflows untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 76/100