Create a consistent relational model API

[AndriySvyryd]

Add a new API that allows to configure and read relational mapping information. Adding this abstraction layer would allow to make the mapping more flexible and the implementation more efficient without additional changes to the consumers.

Some examples of queries that would benefit from this:

• Get all columns for a table
• Get all entity types mapped to a table
• Get all properties mapped to a column
• Get the database object that a navigation/relationship is mapped to

New mapping scenarios that this would be allow:

• Mapping an entity type to more than one table
• Different relational configuration for properties mapped to more than one column
• Different mapping for migrations, query and update pipeline

Tasks:

• Add metadata implementation
• Port migrations
• Port update pipeline
• Port query

[AndriySvyryd]

These are the entity type mappings that can be potentially used for each aspect of EF:

	Nothing	Table	View	Def Query	Sproc	Function
Migrations	✔️	✔️	✔️		✔️	✔️
Query	✔️	✔️	✔️	✔️		✔️
CUD	✔️	✔️	✔️		✔️
Bulk CUD	✔️	✔️
Scaffolding		✔️	✔️		✔️

With table mapping being any of the following:

• Hierarchy mapping strategy (can only use one per hierarachy):
  • TPH: all types in a single table* with a discriminator
  • TPT: each entity type is stored in a table* with columns for only the non-inherited properties, usually linked by an FK in the database
  • TPC: each entity type is stored in a separate table*
  • Inherited Tables (PostgreSQL): Like TPT, but the tables for the derived types also have all columns
• Row mapping strategies (each entity type can have one or more if it doesn’t interfere with other mappings in the hierarchy):
  • Table splitting: multiple entities per row, linked by a metadata-only FK
  • Entity splitting: entity is split across multiple tables*, usually linked by an FK in the database

The following features could be implemented by using the representation described below:

• Separate mappings for different EF aspects Support separation of query and update mapping #15671, To vs From methods: Proposal to rationalize ToTable, ToQuery, ToView, FromSql, and other related methods #17270
• Flexible hierarchy mapping Relational: TPT inheritance mapping pattern #2266, Relational: TPC inheritance mapping pattern #3170, Support PostgreSQL native inheritance #10739, Allow specifying different column names per table in TPT, TPC or entity splitting #19811, Allow more flexible conditional mapping for TPH and similar #10140, Relational: Entity splitting support #620
• Flexible function mapping Query: Additional function mapping capabilities #4319, Map inserts, updates, and deletes (CUD operations) to stored procedures #245, Support flexible entity type to function mapping #19970
• Flexible index mapping Allow mapping a key or index over more than one column across owned entity types. #11336
• Ignore parts of the model for migrations Ability to exclude/skip/ignore parts of the model from migrations so that a table is not created (for overlapping bounded contexts) #2725

Limitations:

• Only one inheritance mapping strategy can be used per hierarchy
• While hierarchy mapping strategies can also be used when mapping to views or functions they can't be mixed in with tables in the same hierarchy

[AndriySvyryd]

The core design:

• Once the model is built and validated the relational model will be generated and stored as annotations.
• When the model is used to find the mapping to use, the possible mapping types will be queried in a specific priority order. For example in Query we would call entityType.GetFunctionMappings() if that returns no result we'll call entityType.GetDefiningQueryMappings(), then entityType.GetViewMappings() and finally entityType.GetTableMappings().
  

This is how the metadata objects will look for each type of mapping strategy:

TPH

TPC

TPT

Table inheritance

Table splitting

Entity splitting

[roji]

While syncing EFCore.PG, ran into the breaking change in 3574cfb (IModelFinalizedConvention/IModelFinalizingConvention), consider opening a separate issue for that (or documenting) as it's provider-breaking.

[ajcvickers]

@roji I thought we talked about this and decided providers-beware was enough. What am I missing?

[roji]

Just that this is an extremely wide issue (maybe an epic really), and this convention change doesn't necessarily seem part of the relational model. If we feel this one issue should cover everything, maybe a small list of breaking changes on it would help track things?

[AndriySvyryd]

That's why it was changed in a separate PR #19872
Do you normally look at fixed issues or PRs for providers-beware?

[roji]

Sometimes :) I do it occasionally when something breaks when I try syncing to the latest, to help understand what's going on. Not critical if you don't feel it's worth it.