Implement many-to-many relationships without mapping join table

[ajcvickers]

This issue tracks work on many-to-many relationships in EF Core. Subscribe to this issue to get updates when progress is made on many-to-many relationships. This issue is locked for now to reduce noise. Please use issue #1368 for general discussion on many-to-many relationships.

[divega]

Current plan for 3.0 is to implement skip-level navigation properties as a stretch goal. If property bags (#9914) also make it into 3.0, enabling a seamless experience for many-to-many could become easier.

[AndriySvyryd]

Consider adding this overload that allows to configure the association table without specifying the type or entity type name.

public virtual EntityTypeBuilder UsingEntity(
            [NotNull] Func<EntityTypeBuilder, ReferenceCollectionBuilder> configureRight,
            [NotNull] Func<EntityTypeBuilder, ReferenceCollectionBuilder> configureLeft,
            [NotNull] Action<EntityTypeBuilder> configureAssociation = null)

[lajones]

@AndriySvyryd I think you may have misunderstood my email. The (slightly different) API I suggested is only indirectly trying to solve the many-to-many issue. I think to directly solve that we do not want a UsingEntity() API at all - it should all "just happen" when you call WithMany().

Instead I was asking, suppose I create an entity type using the non-generic fluent API. (It can be based on a Dictionary<string, object> if we want, but bear in mind there may be many, different such entity types in the model and I will want to refer to my specific one.) At the moment you cannot use the UsingEntity() API with such an entity type because the UsingEntity() APIs require the CLR-type to uniquely identify the entity type. I was asking if it would be useful to provide overloads of UsingEntity() where you can specify such an entity type directly instead of through its CLR-type? Perhaps by name?

If that would be useful independent of trying to fix the many-to-many problem, then the many-to-many code would construct such an entity type, construct the configureRight and configureLeft Func's and call that API.

If not, the many-to-many code would still do all that work, but it would all be behind the scenes, with no public API. I think what users want is for the join table configuration to "just happen" without them having to make any UsingEntity() call at all.

(Note: I'm not saying that users should not be able to further configure the join table, its name for instance is an obvious thing users may want to configure. All I'm saying is they should not have to).

[AndriySvyryd]

@lajones Yeah, I got it. The overload you are proposing falls under #9914. And I proposed a different overload here to allow configuring the implicitly-created association type. I don't see any conflicts between the two.

[lajones]

@AndriySvyryd OK. I hadn't understood that this was additional to what we were discussing - I thought it was instead of. I'll look into the part about configuring the association table as part of the Design Meeting for this.

[lajones]

Re-opening to make sure we agree on what form(s) of configuration of the implicitly-created association entity type are going to be in 5.0.

[ajcvickers]

Many-to-many is now ready to try in the daily builds. Note that we are still finishing up a few things and fixing bugs--see the weekly status update this week for more information and a simple end-to-end example.