Question

我有类似

的课程

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

现在需要将Bar视为CHAR（8），所以我将属性修改为

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

项目中有许多迁移，通常是向现有类添加新类或新属性。我知道我可以生成一个更改列类型的新迁移，但最初将列创建为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
        })

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

我在初始迁移中设置断点，也在上次迁移结束时设置断点。初始迁移完成后，表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（）迁移正在执行创建表时已经完成的操作（并且与模式物理匹配），而Down（）迁移想要将列更改为NVARCHAR（Max），这是从未有过的。 / p>

问题

为什么EF尝试执行这种看似不必要的迁移，我可以在不先创建NVARCHAR（Max）然后在新的单独迁移中将其更改为CHAR（8）的情况下更改列类型吗？

Answer 1

This link描述了迁移过程的内部。此处的问题与嵌入在资源文件中的比较模型有关，该模型用于在创建时生成的迁移。如果更改Up（）Down（）代码，则可能会影响生成的脚本，但不会影响初始比较模型。

建议不要更改这些模型，尽管link显示了如何检查它们。建议的解决方法是创建新的迁移，以便将模型插入其资源文件中。使用-IgnoreChanges标志仅使用模型更新即可创建空白迁移。见https://msdn.microsoft.com/en-us/data/dn579398.aspx?f=255&MSPPError=-2147217396#option1

生成的迁移已经与模式匹配

1 个答案: