Allow to specify constraint name for default values

[dehghani-mehdi]

Hello,

Is there any way to specify constraint name for default values, for example:

        builder.Property(x => x.CreatedDate)
            .IsRequired()
            .HasColumnType("DATETIME")
            .HasDefaultValueSql("GETDATE()")
            .HasConstraintName("DF_MyConstraint");

Thanks

[divega]

@dehghani-mehdi There isn't currently a way to specify a default constraint name.

From the perspective of EF Core, this is not necessary because SQL Sever will generate one for you and we can always address the constraint (e.g. to drop it) without the name through the column (because there can only be one default constraint per column).

However we understand there may be other reasons this can be useful (in fact, you are the second person asking for this). It would be very helpful if you could explain why you need it.

[ErikEJ]

One reason I have experienced is major issues using sqlpackage / SSDT with unnamed constraints

[dehghani-mehdi]

I always using T-SQL instead of wizard for creating tables (or altering them) and I always specify constraint names, I like to have clean names for all things (we have naming convention in our team)
Also I have auto-update system (replacing files/ running updated SQL on the fly) for my projects and in some versions I have to drop some constraint and I need to know the name of them. finding the constraint is possible for specific column but not clean as

ALTER TABLE [TheTable] DROP CONSTRAINT [TheDefaultConstraint]

Maybe the reason that I have is not big enough, but adding this feature will be great.

[divega]

Two click-stops:

1. Generate a deterministic name and specify it in the DDL so that SSDT diffs are stable
2. Allow customizing the name

[CanadianBeaver]

@dehghani-mehdi However we understand there may be other reasons this can be useful (in fact, you are the second person asking for this).

And I am a 3rd person

[rclark381]

My team and I would also like this feature for the reasons mentioned. It provides flexibility for working with a database from different sources (besides through EF Core). Convention in constraint names makes that much easier.

[FaizulHussain]

Count me on too. We too give constraints meaningful names, it gives easy recognition and upgrades via dacpac to multiple databases seamless

[Greg-Smulko]

Another reason is the ability to compare automatically two database schemas. With names of default constraints generated automatically there is a lot of noise reported.

[xrkolovos]

It would be nice to have it in ForeignKey Attribute

[dyslexicanaboko]

Glad I found this post, I was about to open my own for the same topic. I think as a general rule of thumb "If I can do it in tSQL I should be able to do it in EF" is what should be observed. I don't like not knowing what my constraints are called, I like to specify everything in order to stay within explicit over implicit. Implicit makes me nervous.

I feel like SQL Server itself has already dropped the ball by giving constraint names the most inconsistent names possible - so I am just reacting to previous bad experiences of having many client databases with different constraint naming resembling a quarter GUID.

[gambled]

Add me to the list requesting this feature. We too have a coding standard with naming conventions for constraint for not only the reason mentioned by others in this thread, but also for portability/decreased ramp up time of resources from one product to another. It is quite handy when the design document is not detailed enough to call out every single data model rule.

[mikemertes]

Also requesting this feature. This has been bothersome to me for many many years.

I have always thought that default constraints created by EF should be explicitly named in the format "DF_TableName_ColumnName" instead of defaulting to SQL Server generated names (and that behavior should be configurable so the preferred method will be used). Additionally, it should be possible to user-define default constraint names with fluent api to override the context default.

My reasoning being that I should be able to use code first to model an existing schema that was hand designed with traditional tools (SSMS) and get a structurally identical schema when allowing EF to create a new instance in a different database. As someone else mentioned above, if I diff the source schema against a newly generated schema there is a lot of noise because the names don't match.

Creating or renaming the default constraints with migrations feels kludgy.