Migrations: Preserve entity type display name in snapshot

[bricelam]

This also removes any semantics about a shadow entity names.

Fixes #3545

@smitpatel

[smitpatel]

worth putting a comment for this?

[smitpatel]

[bricelam]

Hmm, I hate that this adds an annotation to virtually every entity type in the snapshot...

Any better ideas @ajcvickers @AndriySvyryd @anpete @divega @rowanmiller?

The root of the problem is that the default table name (and thus the key, index, and foreign key names) are based off EntityType.DisplayName() which in turn is based off ClrType (when available) or Name. For "unbound" types, this means that we need to convert Names like My.Ugly+Type<System.Guid, My.Ugly+Struct<int>> into Type<Guid, Struct<int>> which requires string parsing and adds unnecessary semantics to EntityType.Name.

This PR takes away the semantics and captures DisplayName in the snapshot for "unbound" entity types. This removes the need to parse, but adds extra stuff to the snapshot.

[AndriySvyryd]

this.DisplayName() ?

[bricelam]

Which is the lesser of two evils..?

[anpete]

+1 for this

[anpete]

I'm not sure I fully understand this, can we discuss in person?

[ajcvickers]

@bricelam This is a consequence of having shadow state entity types in the snapshot, right? In other words, the model used to create the snapshot has real entity types, but the snapshot model loads these as shadow types, which then causes a difference in behavior with regards to names.

[bricelam]

@ajcvickers Exactly. By converting CLR-backed entity types to shadow entities, we loose some information used by DisplayName.

[anpete]

Could we write the table name annotation instead?

[bricelam]

@anpete Yes, but we'd also have to update constraint names to be based on that (instead of entity type name) which means when you rename a table, all the constraints touching it would also be renamed resulting in a larger diff than expected.

[ajcvickers]

@bricelam Could we annotate with the display name only for generic types?

[anpete]

And possibly we should call the annotation something else

[bricelam]

@ajcvickers The existing code has a few other quarks that I don't like. For example, if I name a shadow entity Post+Contributor, the default table name would be Contributor because we apply CLR type semantics to the name.

[anpete]

@bricelam Could we have a simpler way of producing a table name from a type name string? I.e. not use DisplayName?

[bricelam]

This PR simplifies it to...

1. Use ClrType.DisplayName() (a pretty version of Type.Name)
2. If no ClrType use DisplayName annotation
3. If no annotation, use Name verbatim.

[bricelam]

We could change EntityType.Name... E.g. To trip out generics, but this would prevent you from adding the entity types My.Thing<int> and My.Thing<string> to the same model.

[bricelam]

We could also strip out the namespaces of the generic type arguments which would simplify the conversion:
Name: My.Thing<Guid> (instead of My.Thing<System.Guid> like it currently is)
TableName: Thing<Guid> (same as it currently is)

...but this still applies semantics to Name.

[bricelam]

Recalling. We decided to serialize TableName instead of an annotation and change the constraint names to be based on table name instead of entity type name.