Self-contained type mappings

[divega]

Adding support for a new type on a relational database provider currently requires making changes in a few places:

1. The provider's implementation of IRelationalTypeMapper: used to populate parameters, configure column facets, etc.
2. The provider's implementation of ISqlGenerationHelper: used to generate literal values for a given type in SQL
3. Potentially, CSharpUtilities in Microsoft.EntityFrameworkCore.Relational.Design (and the equivalent types in migrations) to generate C# literals for the type
4. The definition of primitive operations/functions over the type and their LINQ translators
   ... and maybe other things I am missing.

This issue is about refactoring our code to get closer to a situation in which a type mapping can convey the necessary knowledge to perform all or most of those responsibilities for a given type, so that the type mapping can be added to the provider's type mapper and no further actions are required to support the new type.

We should take into account:

1. This should be a stepping stone towards Support for custom type mapping and data store to CLR type conversions #242, which is about having user defined type mappings, and not push us further from it.
2. This should align with Update scaffolding to use ScaffoldingTypeMapper #5410, which is about enabling the use of ScaffoldingTypeMappper in scaffolding.
3. Can we unify the various versions of the code that generate C# (literals and otherwise) between scaffolding and migrations?
4. Does the new factoring help us decide whether we should merge the reverse engineering package into relational (one of the options described in Dissolve Relational.Design into just Relational and Design #7004)?

[ajcvickers]

@lajones Discussed this with @divega and for 2.0 we would be happy with just adding support for string literals to the code we already have for type mapping.

[lajones]

Note: discussed with @ajcvickers and the previous comment means just SQL literals (not C# literals) for now.

[lajones]

The part about SQL literals was checked in with commit 4b8b12d (PR #8568). Will keep this open to address the other issues, but maybe we should change the milestone to 2.0.0?

[lajones]

Note to providers: there may be more changes in this area coming - I will post here when it's safe to go ahead and develop based on the changes.

[lajones]

Further note to providers: with #8631 and #8678, most of the work for individual TypeMappings is in place. In #8668 we are still considering removing HasNonDefaultUnicode and HasNoDefaultSize, but if you base your mappings on the new CLR-type-based mappings introduced in #8631 then only string and byte[] mappings which explicitly set those values would be affected if we decide to remove those APIs.

[ajcvickers]

@lajones Is there anything remaining here that we want to do for preview2?
@divega Do you want to keep this open and in the backlog for C# literals, etc?

[lajones]

@ajcvickers I'd like to do it all, but I thought we were out of time for preview2? I don't have anything small I can just get in today. Would definitely like to do the C# literals in 2.0.0.

[ajcvickers]

@lajones I don't think we're going to do the literals for 2.0 because @bricelam and I talked about it last week and we think we can do it post-2.0 without it being a breaking change.

[lajones]

@ajcvickers @divega OK. I haven't seen the design - is it consistent with the planned approach here to make TypeMappings self-contained? Or are we abandoning that approach - at least as far as the C# literals are concerned? If either of those is true then we can close this, unless @divega has any objections?

[ajcvickers]

Planned approach is to add method to RelationalTypeMapping with a fallback. It is consistent with what we have already done.

[lajones]

OK. I imagine that would mean the removal of the:

public virtual string Literal(SomeType value) {...}

methods in CSharpHelper/CSharpUtilities? Technically that's not a breaking change as the classes are in Internal namespaces. I'd be willing to give that a try in 2.0.0, but maybe there are other reasons for pushing it to post-2.0.0?

[ajcvickers]

Preview2 is the last release to get feature work in for 2.0. (Other than small tweaks or exceptions for super-critical changes.)

[lajones]

Ah, OK - thought we were going to have a preview3. Never mind then.

[divega]

@lajones I talked to @bricelam and @ajcvickers. I don't have any additional concerns with punting C# literals post 2.0.

I am thinking it would be probably be better to capture any outstanding work into new issues rather than keeping this issue open. Could you please help with that?

[lajones]

#8656 covers the issue about finding a more general way for query to deal with generating literals for a type which may not have a TypeMapping in a given provider. #1671 covers combining CSharpHelper and CSharpUtilies - perhaps we could move that issue out of Backlog and update it to include the interaction with RelationalTypeMapping here?

[divega]

@lajones, @ajcvicers @bricelam

I have closed #8656 as fixed (we did remove the pseudo-type mapping for char) and added text to #242 to cover the ideas for mapping char to string.

Would #1671 only require minimal changes to represent the plan for C# literals or is it orthogonal? I think it would be good if someone with a good understanding of the plan (@bricelam?) filled the details there. After that, I think this issue can be closed as fixed.

[bricelam]

It's mostly orthogonal to #1671. If we don't de-dupe, we'll just have two entry points for generating C# literals that do the same thing (like we do today).

[divega]

@bricelam understood. Cleared up the milestone to get more clarity in triage on Monday on how to proceed.

[ajcvickers]

@bricelam to write the issue for C# literals.

[bricelam]

Filed #8741