-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store database type name in model snapshot #16484
Conversation
Fixes #16239 Fixes #12212 Also, make the SnapshotModelProcessor finalize the model. I investigated whether it would be better to only store this sometimes, but that then still requires making some assumptions (basically using some conventions and/or the type mapper doing what it does in conventions) when loading the snapshot to ensure we find the right type for the provider being used. Storing it always is clean and simple, decouples from conventions when loading, and means we don't have to do special magic for facets that come from value converters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.Append(".") | ||
.Append(nameof(RelationalPropertyBuilderExtensions.HasColumnType)) | ||
.Append("(") | ||
.Append(Code.UnknownLiteral(property.GetColumnType())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code.Literal()
is preferred when they type is statically known.
|
||
b.Property<decimal>(""EnumU64"") | ||
.HasConversion(new ValueConverter<decimal, decimal>(v => default(decimal), v => default(decimal), new ConverterMappingHints(precision: 20, scale: 0))); | ||
.HasColumnType(""decimal(20,0)""); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
Fixes #16239
Fixes #12212
Also, make the SnapshotModelProcessor finalize the model.
I investigated whether it would be better to only store this sometimes, but that then still requires making some assumptions (basically using some conventions and/or the type mapper doing what it does in conventions) when loading the snapshot to ensure we find the right type for the provider being used. Storing it always is clean and simple, decouples from conventions when loading, and means we don't have to do special magic for facets that come from value converters.