Reputation: 6369
I am using EF Core 6 Code First approach. When I define a new entity with a required field, EF migrations create for that always an empty default constraint like here:
migrationBuilder.AlterColumn<Guid>(
name: "TenantId",
table: "Sites",
type: "uniqueidentifier",
nullable: false,
defaultValue: new Guid("00000000-0000-0000-0000-000000000000"), // unnecessary default constraint
oldClrType: typeof(Guid),
oldType: "uniqueidentifier",
oldNullable: true);
In most cases, I do not want to have any default value. I tried to disable this behavior with a model configuration like this, but it has no effect:
builder.Property(cc => cc.TenantId).HasDefaultValue(null);
builder.Property(cc => cc.TenantId).HasDefaultValueSql(null);
I am using this command for generating the migrations:
dotnet ef migrations add --context:DataContext --project "xxx" xxxx
I couldn't find any question on SO for this particular issue, but there are a lot of similar questions leading to one answer: just update the generated scripts manually.
That feels strange to me. So far, I have never updated the scripts manually, I think a manual update to the script will lead to a discrepancy between the code and the DB schema. If the manual change in the script is the way to go, could you please explain why that is not a problem and why I should not be worried?
many thanks!
additional details:
// Nullable types are not enabled
public class Site
{
public Tenant Tenant { get; set; }
public Guid TenantId { get; set; }
public Guid Id { get; set; }
...
}
public class Tenant
{
public Guid Id { get; set; }
...
}
public class SiteEntityTypeConfiguration : IEntityTypeConfiguration<Site>
{
public void Configure(EntityTypeBuilder<Site> builder)
{
builder.HasOne(cc => cc.Tenant)
.WithMany()
.OnDelete(DeleteBehavior.Restrict);
}
}
Upvotes: 5
Views: 1932
Reputation: 13148
The idea, I think, is to allow database migrations. That is, to be able to update a live database incrementally. This means that new columns MUST have a default value, or else you would not be able to apply a migration that adds a column if there was any data in the table. (The new column needs a source of values for the existing rows.)
Notice that if the table is being newly created rather than adding a new column to an existing table, then the column does not get a default value specifier unless you add one.
For the most part, column default values in the DB shouldn't matter too much when using EF since I think EF will always give a value for each column explicitly.
Upvotes: 0
Reputation: 341
Well....you shouldn't worry, but then maybe you should.
You shouldn't worry about manually changing the script because it doesn't really affect the runtime behavior. The default value only affects the SQL side of things and not the POCO side.
In other words, if you create a new instance of the POCO, whatever default constraints you have (or do not have) in the database have no effect on the values in that new POCO instance.
However, you should worry about it from a code maintenance perspective, which is why I came to this thread also looking for a way to prevent the default constraint from being created in the first place. If we had a way to do this we could make our code self-documenting for other developers and ourselves in the future when we look at it and ask, "why does this column not have a default constraint yet all the others do?".
Upvotes: 1
Reputation: 10242
You cannot have a [Required] property have a null default value. This would be against the constraint.
If a property is required, it will be marked as NON NULLable in the database. So you cannot use null as default.
Upvotes: -1