Entity framework 通过ObjectContext编写EF 4.3代码优先数据库脚本失败，而通过内置DatabaseInitializer创建成功

我想以编程方式为EF 4.3代码优先数据库创建数据库创建脚本。数据库使用标准DatabaseInitializer机制创建得很好，但以下代码失败：

using(var dc = new MyContext())
{
    var objContext = (IObjectContextAdapter)dc;
    var script = objContext.ObjectContext.CreateDatabaseScript();
}

我得到的例外是：

非“timestamp”或“rowversion”类型的属性不支持存储生成的模式“Computed”

我确实有一个定义为“string”类型的计算列，但正如我所说的，当通过内置的DatabaseInitializer创建时，数据库创建得很好。奇怪的是，使用此方法生成的模式实际上并没有创建计算列

---

至于我为什么要这样做，我有一个脚本，它运行post create，删除这个列并创建一个真正的计算列。在不指定EF映射中计算的列的情况下，它将尝试在插入时为该列赋值，然后失败

暂时搁置数据库创建，设置“Computed”意味着EF不会尝试写入该列的值，而是会在每次查询该列时读取服务器（可能）在计算机上读取的值。从EF的角度来看，任何数据类型都可以使用计算列

现在考虑从EF模型创建数据库。EF不知道如何在数据库中创建计算列，事实上，根据列的类型，在某些数据库中，如果没有触发器，甚至不可能创建计算列。因此在EF4中，决定在这些情况下抛出CreateDatabaseScript

但是，EF4.3及更高版本在针对SQL Server或SQL Server Compact时不再使用CreateDatabaseScript。他们转而使用迁移管道。对于迁移管道，我们决定采用一种不同的方法，因为我们觉得数据库创建总是抛出一个完全有效的模型是错误的。特别是考虑到您可以在迁移中编写自己的SQL，添加触发器或其他机制，使数据库创建有效的计算列

这就是为什么您看到数据库是由EF 4.3创建的（但是没有做任何事情来计算列），但是当您尝试使用CreateDatabaseScript时，您会看到相同的模型抛出，该脚本使用了较旧的非迁移机制

---

解决这一问题的方法是让迁移创建脚本，而不是使用CreateDatabaseScript。

我一直与迁移有分歧，从我最近的一些问题可以看出。对实际数据库的依赖是有问题的。出于我无法控制的原因，我需要能够简单地获取DDL脚本，无论它是从一个迁移到另一个迁移的“diff”脚本，还是任何给定点的整个create脚本。