生成的迁移已与架构匹配

Migration Generated that Already Matches Schema

我有一个class像

public class Foo
{
    public virtual string Bar { get; set; }
    // Other Stuff
}

现在需要像对待 CHAR(8) 一样对待 Bar 所以我将 属性 修改为

    [StringLength(8)]
    [Column(TypeName = "char")]
    public virtual string Bar { get; set; }

项目中有许多迁移,通常是向现有 classes 添加新的 classes 或新属性。我知道我可以生成一个新的迁移来更改列类型,但是最初将列创建为 NVARCHAR(Max) 然后将其更改为 CHAR(8) 似乎有点令人费解。我编辑了初始迁移,改变了

CreateTable(
    "dbo.Foo",
    c => new
        {
            Bar = c.String(),
            // Other stuff
        })

CreateTable(
    "dbo.Foo",
    c => new
        {
            Bar = c.String(maxLength: 8, fixedLength: true, storeType: "char", unicode: false),
            // Other stuff
        })

然后我删除了数据库和 运行 使用上下文的程序,从而重新创建了数据库。

我在初始迁移和最后一次迁移结束时都设置了断点。一旦初始迁移完成,就会在新创建的数据库中创建 table Foo,其列类型为 CHAR(8)。 最终迁移完成后,我尝试使用上下文,我得到一个 AutomaticMigrationsDisabledException

然后我编写了一个迁移脚本以查看 EF 的不同之处,并得到

public override void Up()
{
    AlterColumn("dbo.Foo", "Bar", c => c.String(maxLength: 8, fixedLength: true, unicode: false));
}

public override void Down()
{
    AlterColumn("dbo.Foo", "Bar", c => c.String());
}

Up() 迁移正在执行创建 table 时已经完成的操作(并且与模式物理匹配),而 Down() 迁移想要将列改回 NVARCHAR(Max),从来没有。

问题

为什么 EF 会尝试执行这种看似不必要的迁移,我是否可以更改列类型而不先创建 NVARCHAR(Max),然后在新的单独迁移中将其更改为 CHAR(8)?

This link 描述了迁移过程的内部结构。这里的问题与嵌入在创建时生成的迁移的资源文件中的比较模型有关。如果您更改 Up() Down() 代码,您可能会影响生成的脚本,但不会影响初始比较模型。

不建议更改这些模型,尽管 link shows how you can inspect it. The advised workaround is to create a new migration so the model is inserted into it's resource file. Use the -IgnoreChanges flag to create a blank migration with just a model update. See https://msdn.microsoft.com/en-us/data/dn579398.aspx?f=255&MSPPError=-2147217396#option1