Re-consider One Model to Rule Them All

[ajcvickers]

Many moons ago we decided to follow the path of One Model to Rule Them All. That is, the ability to create a single model that can be used by all providers. To this end:

• Annotations and the APIs around them were implemented such that any provider-specific annotations could co-exist on the model with provider-specific annotations for a different provider.
• Provider-specific conventions would not structurally change the model.

However, several aspects of where we have ended up mean that we may want to reconsider this:

• The TPH implementation introduces a discriminator property, thereby structurally changing the model.
• By default, we create and cache one model per provider, so even though it is possible to create one model for many providers, the usual path is not this.
• We have backed off on automatic Migration generation/scaffolding for all registered providers.
• We have not implemented running conventions for all registered providers, so we currently only run the conventions for the current provider.
• The switch to an internal service provider by default means we are considering changing the provider model to allow only one provider per internal service provider.

Switching to one model per provider would have the following advantages:

• Provider-specific conventions could structurally change the model without issues. (We have, as far as we know, worked around the discriminator issues so that, at least for the in-memory provider, it is okay to have the discriminator property present. However, it really still doesn't make sense that it is there, and beyond the discriminator issue there could be future conventions that generate similar problems.)
• Provider-specific behaviors could be built into the model more explicitly. For example, rather than adding abstract information indicating that some form of provider-specific value generation is needed, the model could have a specific value generator set at model building time, removing the need for value generator selection.
• We would not need to implement the code to run all provider conventions, and we would not need to deal with any conflicts resulting from this.
• We could simplify the annotation story, especially for relational annotations, by only ever putting in the "Relational:" annotation. If SQLite needs a different annotation value than SQL Server, then this would be automatically handled by having two different models. The big advantage of this is that relational-level consuming code does not need to indirect through the provider to read relational values.
• If we wanted, we could remove the ForSqlServerColumnType methods and instead have a general way of testing what the current provider is in OnModelCreating. This would also allow core things like MaxLength to vary by provider in a natural way.

Note that provider-agnostic migrations would still be possible in the same way they are today--by adding code to switch on the current provider in an edited migration.

[ajcvickers]

Done enough for preview2, moving out for any remaining work.

[ajcvickers]

Looked at the value generator stuff and decided to not change it for now. Some generators need to access scoped services, which can't be done in an obvious way if they are configured directly on the model. Maybe come 3.0 we'll revisit... ;-)