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.

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

Enable nullable backing field pattern for store-generated defaults #15182

Closed
ajcvickers opened this issue Mar 27, 2019 · 2 comments · Fixed by #21351
Closed

Enable nullable backing field pattern for store-generated defaults #15182

ajcvickers opened this issue Mar 27, 2019 · 2 comments · Fixed by #21351
Labels
area-change-tracking closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. punted-for-3.0 type-enhancement
Milestone

Comments

@ajcvickers
Copy link
Member

See discussion here: #15070 (comment)

Enable this:

public class Blog
{
    private bool? _isValid;

    public bool IsValid
    {
        get => _isValid ?? false;
        set => _isValid = value;
    }
}

and

    .HasDefaultValue(true);

(There should be no need to set the property access mode since we read/write fields by default in 3.0.)

This pattern means:

  • The column has a default constraint in the database
  • If the property is never set, then no value will be included in the insert, and hence the store default will be used.
  • If the property is set to anything (true or false) in this example, then that value will be explicitly included in the insert.
@ajcvickers ajcvickers added this to the 3.0.0 milestone Mar 27, 2019
@ajcvickers ajcvickers self-assigned this Mar 27, 2019
ajcvickers added a commit that referenced this issue May 27, 2019
Fixes #15182

There is quite a fundamental change included here: the CLR type reported for a mapped property is now the backing field type, if it is known, not the property type. This is what allows a three states to be saved for a non-nullable property with a nullable backing field.

Perceptive readers will realize that this means that the CLR type of an `IProperty` can now change if the backing field is changed.

The most difficult case to handle seems to be properties backed by `object` fields. This likely isn't very common, but we had tests for it because of previous issues reported. One scenario is not working here--creating a shadow property FK by convention for a PK that is backed by an object field. I will file a bug for this.

Query changes are just what I needed to do to re-enable some tests to get coverage for this change. In particular, the type inference is not a universal solution, but unblocks important tests.
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label May 27, 2019
@ajcvickers ajcvickers removed the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jun 3, 2019
@ajcvickers ajcvickers modified the milestones: 3.0.0, Backlog Jun 28, 2019
@ajcvickers ajcvickers modified the milestones: Backlog, 5.0.0 Nov 20, 2019
@ajcvickers
Copy link
Member Author

Consider #12215 when working on this.

@ajcvickers
Copy link
Member Author

See also scenario in #20148

ajcvickers added a commit that referenced this issue Jun 20, 2020
Fixes #15182

This allows a null backing field to be used for a non-nullable property while at the same time checking the backing field for null in order to determine if a property value has been set.
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jun 20, 2020
ajcvickers added a commit that referenced this issue Jun 20, 2020
Fixes #15182

This allows a null backing field to be used for a non-nullable property while at the same time checking the backing field for null in order to determine if a property value has been set.
ajcvickers added a commit that referenced this issue Jun 20, 2020
Fixes #15182

This allows a null backing field to be used for a non-nullable property while at the same time checking the backing field for null in order to determine if a property value has been set.
ajcvickers added a commit that referenced this issue Jun 21, 2020
Fixes #15182

This allows a null backing field to be used for a non-nullable property while at the same time checking the backing field for null in order to determine if a property value has been set.
ajcvickers added a commit that referenced this issue Jun 21, 2020
Fixes #15182

This allows a null backing field to be used for a non-nullable property while at the same time checking the backing field for null in order to determine if a property value has been set.
@ajcvickers ajcvickers modified the milestones: 5.0.0, 5.0.0-preview7 Jun 22, 2020
@ajcvickers ajcvickers modified the milestones: 5.0.0-preview7, 5.0.0 Nov 7, 2020
@ajcvickers ajcvickers removed their assignment Sep 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-change-tracking closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. punted-for-3.0 type-enhancement
Projects
None yet
1 participant