-
Notifications
You must be signed in to change notification settings - Fork 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
Document C# 8 nullable reference types #1709
Conversation
bab0353
to
4d01b62
Compare
So there's a new "nullable reference types" under "miscellaneous" (which is accessible under "fundamentals" in the site TOC, we're changing that right?), plus some additional changes in other pages.
|
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.
Some suggestions.
@@ -0,0 +1,64 @@ | |||
--- |
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.
Add this file to the ToC?
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.
Will do, but was hesitating where to put it. As it's cross-cutting (modeling, querying...), it seems like it would fit well in a Miscellaneous section - see #1726. Will add it under Fundamentals for now.
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.
Oh, you are right, and this got me thinking... Whether we add or not an article focused on nullable reference types to the EF Core docs, the main thing we should be focusing on is making sure we enhance existing pages with information relevant to nullable reference types.
For example:
- The main place information on nullable reference types is in core/modeling/required-optional article. Adding the information there is coherent with the fact that form the EF Core perspective, there is a single concept of nullability/requiredness, and we want to treat nullable value types, nullable reference types and the
[Required]
attribute all the same as much as possible. - The part about initialization belongs in some topic about modeling entity properties.
- Though the comments specific to the initialization of DbSets belongs probably in working with DbContext.
Understandably nullable reference types are new and us and our customers have learned a lot about them very recently, but if we make nullable reference types too special in the EF Core docs, I don't think that is great. Long term NRT should become routine, more or less just like using Nullable<T>
is routine today, and we don't maintain a dedicated page about Nullable<T>
in the EF Core docs.
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.
I agree that we should add NRT-related notes to the property modeling articles and DbSet/DbContext articles. At the same time, at least in the foreseeable future NRTs is a new feature and we should probably have a dedicated page for migrating to it, much like we have an EF6->Core migration page - just to concentrate all the relevant information in a single place for people thinking about moving and wanting to understand all the consequences.
Some links back and forth are OK, and if we end up with some duplication I don't think it's the end of the world either...
If that sounds good I'll work on refactoring the information into the specific articles too.
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.
Yeah, sounds good if you are convinced. Though I prefer the dedicated page to be mostly links to the other ones. As you say, it is a cross cutting feature. We need the information to be included where it matters. Also, new features are supposed to go in “what’s new”, and aspects of migrating to new versions can go to an article about upgrading to 3.0. We have an issue for creating the later.
entity-framework/core/miscellaneous/nullable-reference-types.md
Outdated
Show resolved
Hide resolved
|
||
This page introduces EF Core's support fo nullable reference types, and describes best practices for working with them. | ||
|
||
## Required and optional properties |
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.
Consider only including a short paragraph and a link to the required-optional article rather than entirely duplicating its contents here.
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.
OK. Note that means we'd have links going both ways, but it seems fine.
@@ -0,0 +1,64 @@ | |||
--- |
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.
Oh, you are right, and this got me thinking... Whether we add or not an article focused on nullable reference types to the EF Core docs, the main thing we should be focusing on is making sure we enhance existing pages with information relevant to nullable reference types.
For example:
- The main place information on nullable reference types is in core/modeling/required-optional article. Adding the information there is coherent with the fact that form the EF Core perspective, there is a single concept of nullability/requiredness, and we want to treat nullable value types, nullable reference types and the
[Required]
attribute all the same as much as possible. - The part about initialization belongs in some topic about modeling entity properties.
- Though the comments specific to the initialization of DbSets belongs probably in working with DbContext.
Understandably nullable reference types are new and us and our customers have learned a lot about them very recently, but if we make nullable reference types too special in the EF Core docs, I don't think that is great. Long term NRT should become routine, more or less just like using Nullable<T>
is routine today, and we don't maintain a dedicated page about Nullable<T>
in the EF Core docs.
> [!NOTE] | ||
> Exercise caution when enabling nullable reference types on an existing project: reference type properties which were previously configured as optional will now be configured as required, unless they are explicitly annotated to be nullable. When managing a relational database schema, this may cause migrations to be generated which alter the database column's nullability. | ||
|
||
## DbContext and DbSet |
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.
This entire section would probably go into core/miscellaneous/configuring-dbcontext. The only problem is that we don't have there the basics of adding DbSets to include a type in the model.
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.
I find that page a bit confusing and not necessarily suitable for newcomers (e.g. it starts with "Design-time DbContext configuration" which seems very specific and somewhat advanced). I think core/modeling/index could be a better candidate. But see also my comments above on a specific nullability page etc.
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.
Yes, I agree the configuring DbContext page can be improved, reorganized, and that some of the more basic/introductory content is currently missing from it. However it exists for good reasons and many of the more advanced things including in it are there because they happen to be too common pitfalls that we have been forced to document.
If the root modeling page is a better candidate to explain how the DbSets on the DbContext contribute to the model, I guess the configuring DbContext page should have a paragraph and a link to that page too.
entity-framework/core/miscellaneous/nullable-reference-types.md
Outdated
Show resolved
Hide resolved
> [!NOTE] | ||
> Exercise caution when enabling nullable reference types on an existing project: reference type properties which were previously configured as optional will now be configured as required, unless they are explicitly annotated to be nullable. When managing a relational database schema, this may cause migrations to be generated which alter the database column's nullability. | ||
|
||
## DbContext and DbSet |
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.
Yes, I agree the configuring DbContext page can be improved, reorganized, and that some of the more basic/introductory content is currently missing from it. However it exists for good reasons and many of the more advanced things including in it are there because they happen to be too common pitfalls that we have been forced to document.
If the root modeling page is a better candidate to explain how the DbSets on the DbContext contribute to the model, I guess the configuring DbContext page should have a paragraph and a link to that page too.
@divega I've merged your suggestions. I agree that we should integrate NRT information in various relevant pages rather than only in a single page (#1709 (comment)), but that requires a more complete rethinking/restructuring of the docs (interacts with modeling changes in #1669, work on the DbContext page, etc.). So unless you object I suggest we merge this PR as-is - it's sub-optimal but it does provide complete information right away for 3.0. I'll open a separate issue to track introducing NRT information into the other relevant pages, link back and forth etc. Does that sound OK? |
Note: am working on some further improvements on this PR, especially with regards to the samples. |
933d29e
to
4406495
Compare
I am ok with this plan. |
61543ee
to
e9f3d09
Compare
Thanks @divega! Have made some improvements and will merge. |
Closes #1654
Closes #1655