Migrations: Inconsistency between migration and Script-DbContext when adding a required string property.

[minichma]

When adding a required string property to an entity, the corresponding migration will generate a default value of "" (empty string). When scripting the DbContext from scratch using Script-DbContext, no default value is generated.

E.g. migrate from

        modelBuilder.Entity(
              "Customer", e =>
              {
                  e.Property<int>("Id").ValueGeneratedOnAdd();
                  e.ToTable("Customers");
              });

to

        modelBuilder.Entity(
              "Customer", e =>
              {
                  e.Property<int>("Id").ValueGeneratedOnAdd();

                  // Generates a migration with a default value of "" specified.
                  // When scripting the context from scratch, no default value is created.
                  e.Property<string>("Foo").IsRequired();

                  e.ToTable("Customers");
              });

Add-Migration and subsequent Script-Migration will generate an SQL like the following (note the DEFAULT N''):

CREATE TABLE [Customers] (
    [Id] int NOT NULL IDENTITY,
    CONSTRAINT [PK_Customers] PRIMARY KEY ([Id])
);
GO

...

ALTER TABLE [Customers] ADD [Foo] nvarchar(max) NOT NULL DEFAULT N'';
GO

Script-DbContext will generate something like the following (no default value for Foo):

CREATE TABLE [Customers] (
    [Id] int NOT NULL IDENTITY,
    [Foo] nvarchar(max) NOT NULL,
    CONSTRAINT [PK_Customers] PRIMARY KEY ([Id])
);
GO

Seems to be related to #33038.

[Edit] Fixed reproducing example.

[ajcvickers]

Note for team: this is currently by-design. We generate the default value for the Alter to account for existing columns. Script-DbContext is creating a new database, so it does not need to handle existing rows.

[minichma]

Thank you for investigating this issue! I am convinced that the database generated from the migrations should align with a newly created database (via Script-DbContext). If not, it would require us to manage discrepancies during the development process, particularly in testing, which significantly increases complexity.

Regarding default values, I don’t see their value in migrations. If default values are not explicitly set by the user, then it’s likely that no appropriate default exists. This is especially true for foreign keys, for which default values are currently generated as well. Automatically setting defaults could even obscure issues that would otherwise be detected.

[ajcvickers]

@minichma This is tracked by #27084.