You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The call to UsingEntity<PostTag>() has those 2 lambdas, the first one with a parameter of l and the 2nd with a parameter named r, suggesting "left" and "right".
The problem is that the UsingEntity method signature has those reversed, where "right" is first, then "left". Like this: UsingEntity(Func<...> configureRight, Func<...> configureLeft) The sample suggests the parameter order is (left, right) when in actuality it is (right, left).
Yes, type checking should prevent the user from doing something invalid, but it may confuse developer as to what is considered "left" and what is considered "right".
Type of issue
Other (describe below)
Description
In the docs about how to configure many-to-many relationships with a class for a join entity:
https://learn.microsoft.com/en-us/ef/core/modeling/relationships/many-to-many#many-to-many-with-class-for-join-entity
The code sample looks like this:
The call to
UsingEntity<PostTag>()
has those 2 lambdas, the first one with a parameter ofl
and the 2nd with a parameter namedr
, suggesting "left" and "right".The problem is that the
UsingEntity
method signature has those reversed, where "right" is first, then "left". Like this:UsingEntity(Func<...> configureRight, Func<...> configureLeft)
The sample suggests the parameter order is (left, right) when in actuality it is (right, left).Yes, type checking should prevent the user from doing something invalid, but it may confuse developer as to what is considered "left" and what is considered "right".
Page URL
https://learn.microsoft.com/en-us/ef/core/modeling/relationships/many-to-many#many-to-many-with-class-for-join-entity
Content source URL
https://github.com/dotnet/EntityFramework.Docs/blob/main/entity-framework/core/modeling/relationships/many-to-many.md
Document Version Independent Id
9234f104-802f-8ee0-8a54-ff3b8f49857e
Article author
@ajcvickers
The text was updated successfully, but these errors were encountered: