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

Allow default value check in value generation to be customized #701

Closed
Tracked by #22954
ajcvickers opened this issue Sep 25, 2014 · 5 comments · Fixed by #30760
Closed
Tracked by #22954

Allow default value check in value generation to be customized #701

ajcvickers opened this issue Sep 25, 2014 · 5 comments · Fixed by #30760
Labels
area-change-tracking closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Milestone

Comments

@ajcvickers
Copy link
Member

Currently we generate a value for a property on Add when it is marked as needing value generation in metadata and the current value is the default for the type of property. It should be possible to customize the latter check to change the this sentinel value, make it a more complex check (e.g. negative numbers) or so that values are always generated regardless of the current value. This is probably best done with a Func in the model, but note this requires we implement the ability to annotate a model with code snippets.

@ajcvickers
Copy link
Member Author

ajcvickers commented Mar 27, 2019

See also the discussion in #15070 (comment)

Use of a different sentinel value could be useful here if it is set to the same as the default value.

  • This would mean that if the value is set to default, then it would not be inserted, since this value is the same as the sentinel. But it would get the default value from the database as expected.
  • However, this would be a breaking change since it would insert the CLR default rather than using the default from the database
  • We could even consider automatically making the default value the same as the sentinel value if it has been set.

@roji
Copy link
Member

roji commented Oct 11, 2022

This could be more relevant with non-nullable reference types. For example, non-nullable string properties can no longer default to null (unless bang is used), so it makes sense for many cases to initialize it e.g. to an empty string. But EF still uses null as the uninitialized sentinel value (to trigger value generation).

ajcvickers added a commit that referenced this issue Apr 25, 2023
…as not been set

Fixes #701

Part of #13224, #15070, #13613

This PR contains the underlying model and change tracking changes needed to support sentinel values. Future PRs will add model building API surface and setting the sentinel automatically based on the database default.

There is a breaking change here: explicitly setting the value of a property with a temporary value no longer automatically makes the value non temporary.
@ajcvickers ajcvickers modified the milestones: Backlog, 8.0.0 Apr 25, 2023
@ajcvickers ajcvickers added closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. and removed consider-for-current-release labels Apr 25, 2023
ajcvickers added a commit that referenced this issue Apr 28, 2023
…as not been set

Fixes #701

Part of #13224, #15070, #13613

This PR contains the underlying model and change tracking changes needed to support sentinel values. Future PRs will add model building API surface and setting the sentinel automatically based on the database default.

There is a breaking change here: explicitly setting the value of a property with a temporary value no longer automatically makes the value non temporary.
ajcvickers added a commit that referenced this issue May 2, 2023
@ajcvickers ajcvickers modified the milestones: 8.0.0, 8.0.0-preview4, 8.0.0-preview5 May 26, 2023
@ajcvickers ajcvickers modified the milestones: 8.0.0-preview5, 8.0.0 Nov 14, 2023
@risperdal

This comment was marked as resolved.

@roji

This comment was marked as resolved.

@risperdal

This comment was marked as resolved.

@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. type-enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants