Non-nullable shadow property problem
See original GitHub issueHi there,
If I specify a string property in an entity type class as
public string Test2 { get; set; } = null!;
it gets correctly picked up as non-null ("Test2" TEXT NOT NULL
) in the create statement.
If I specify the same property as a shadow property via
modelBuilder
.Entity<MyEntity>()
.Property<string>("Test1");
it is nullable ("Test1" TEXT NULL
) in the create statement.
This seems like a bug or am I doing something wrong?
Further technical details
EF Core version: 5.0.0-preview.8.20407.4 Database provider: Sqlite Target framework: .NET Core 3.1 latest (nullable enabled) Operating system: Windows 10 latest IDE: Rider latest
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (6 by maintainers)
Top Results From Across the Web
Issue with Entity Framework 7 Shadow Property
I have a shadow property named CreatedBy. EF correctly loads its value from data store, the value of this property remains accessible as...
Read more >Allow not null setter and getter for nullable property : KT-24691
Shadow property workaround works but bloats up DTO code and causes field naming issues in validation error reports. @JsonAutoDetect(fieldVisibility = Visibility ...
Read more >Foreign and principal keys in relationships - EF Core
Foreign key properties can be created as shadow properties. A shadow property exists in the EF model but does not exist on the...
Read more >EF Core Advanced Topics - Nullable Reference Types
When mapping to a relational database schema, the required properties are created as non-nullable columns, and optional properties are created as nullable ......
Read more >Typed Forms
This type is shorthand for specifying {nonNullable: true} on every control, and can eliminate significant boilerplate from large non-nullable forms. You can ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Hey thanks @roji , great info! I see NRT as following the TypeScript model where you allow compile-time and run-time languages to diverge to add new features without modifying the run-time language. However I do hope at some point the run-time language (CLR) is updated to natively support NRT as this would simplify the whole feature and avoid increasing use of reflection which is not great for performance/debugging/analyzers/etc. Just my thoughts, have a great day!
Not sure there is anything to do here… For shadow properties specifically, as written above, the runtime Type for generic type parameters lacks NRT information (by design). For non-shadow generic properties, our current NRT metadata decoding indeed doesn’t support them because of the complexities involved. However, using the new .NET decoder should fix this - already tracked by #24744.