Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Clarify that the NRT feature was unsupported before EF Core 6 #3603

Merged
merged 1 commit into from
Dec 14, 2021
Merged

Clarify that the NRT feature was unsupported before EF Core 6 #3603

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion entity-framework/core/managing-schemas/scaffolding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -151,7 +151,7 @@ Finally, the model is used to generate code. The corresponding entity type class
* Not everything about a model can be represented using a database schema. For example, information about [**inheritance hierarchies**](xref:core/modeling/inheritance), [**owned types**](xref:core/modeling/owned-entities), and [**table splitting**](xref:core/modeling/table-splitting) are not present in the database schema. Because of this, these constructs will never be reverse engineered.
* In addition, **some column types** may not be supported by the EF Core provider. These columns won't be included in the model.
* You can define [**concurrency tokens**](xref:core/modeling/concurrency), in an EF Core model to prevent two users from updating the same entity at the same time. Some databases have a special type to represent this type of column (for example, rowversion in SQL Server) in which case we can reverse engineer this information; however, other concurrency tokens will not be reverse engineered.
* Prior to EF Core 6, [the C# 8 nullable reference type feature](/dotnet/csharp/tutorials/nullable-reference-types) wasn't unsupported in reverse engineering: EF Core always generated C# code that assumed the feature is disabled. For example, nullable text columns were scaffolded as a property with type `string` , not `string?`, with either the Fluent API or Data Annotations used to configure whether a property is required or not. If using an older version of EF Core, you can still edit the scaffolded code and replace these with C# nullability annotations.
* Prior to EF Core 6, [the C# 8 nullable reference type feature](/dotnet/csharp/tutorials/nullable-reference-types) was unsupported in reverse engineering: EF Core always generated C# code that assumed the feature is disabled. For example, nullable text columns were scaffolded as a property with type `string` , not `string?`, with either the Fluent API or Data Annotations used to configure whether a property is required or not. If using an older version of EF Core, you can still edit the scaffolded code and replace these with C# nullability annotations.

## Customizing the model

Expand Down