Entityframework.docs: Default Values

[CubeSpark]

The technique described is inefficient for one reason. The reason is that the database engine already handles default values on any column with a DEFAULT constraint during inserts. These DEFAULT CONSTRAINTS are a defined in standards from the ISO/IEC 9075-2:1999, Section 11.5 in the SQL Database engine. This is implemented effectively in the database engine at table design time, and the entire default constraint infrastructure is well tested on the database engine. What Use Case does Entity Framework have that would require an exception, wherein a default value would have to be created by EF Core when a row is inserted with no values for columns needing a default? Why not let the database engine do that?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1f32ff95-761b-279a-f5a9-7fe859121356
• Version Independent ID: 63cc902d-8261-8185-d0a0-c48c627234b1
• Content: Default Values - EF Core
• Content Source: entity-framework/core/modeling/relational/default-values.md
• Product: entity-framework
• GitHub Login: @rowanmiller
• Microsoft Alias: divega

[ajcvickers]

@CubeSpark EF creates and/or uses the default constraint on the column. Not sure which "technique" you are referring to that is different from this.

[BruceCarson]

@CubeSpark : @ajcvickers is referring to "code-first" development, where EFCore creates the tables. This is useful for smaller projects / organizations, but impractical in most organizations because the database team is responsible for creating the tables. I also dislike it because it requires the app to have table creation permissions.

[ajcvickers]

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.