【发布时间】：2015-12-05 14:33:09
【问题描述】：
我正在努力了解如何使用 Entity Framework Code First 迁移来定位多个相同的 Oracle 数据库，其中每个数据库都存在于自己的架构中。我发现其他人也有同样的问题 - 查看了几个论坛，之前几乎已经提出了确切的问题：
Schema independent Entity Framework Code First Migrations
我们使用自己的自托管 Oracle 数据库为多个客户提供服务，并且我们针对包含多个客户端数据库副本的 Oracle 数据库进行开发，每个客户端都分为自己的用户/模式，例如：
客户端 1
- 表一
- 表2
客户端 2
- 表一
- 表2
问题源于坚持使用显式架构与 Code First 迁移，“dbo”（Code First 默认）或由以下指定的其他架构：
modelBuilding.HasDefaultSchema(“SchemaName”)
这意味着一组针对 SQL Server 数据库的迁移，使用默认架构“dbo”，可用于更新任何匹配的数据库（上例中的客户端 1 或客户端 2）。
但是，在 Oracle 系统上，迁移最终将绑定到特定架构，这意味着迁移仅适用于其中之一，即如果迁移是针对 Client 1 架构生成的，但应用程序被指向在客户端 2 上，它不起作用。
以下是我处理这个问题的一些想法，以及我尝试过的解决方案：
使用 HasDefaultSchema(String.Empty)。这在生成初始迁移时失败，并出现错误：“值不能为空。参数名称：seqOwner”。这向我表明，OracleMigrationSqlGenerator 不打算在没有特定架构名称的情况下工作。
找到某种方法从当前连接字符串中提取 Oracle 用户名，并将其用作迁移中的模式名称。我已经不得不在应用程序本身中执行此操作，以阻止实体框架在“dbo”架构中查找 Oracle 数据库，但这是通过在构建模型时检查 ConfigurationManager.ConnectionStrings 来完成的，我不确定如何从内部迁移代码中也可以实现同样的效果。
与 #2 类似，但只是在某处使用变量 - 可能在 Web.config 的 appsettings 元素中，用于存储 Oracle 架构，并从迁移代码中引用它。然后，Oracle 迁移脚本将引用此变量来查找模式。不过，这和 #2 看起来都非常 hacky。
如何实现上述目标，使用上述方法 2/3 会有什么重大问题吗？我觉得我必须在这里遗漏一些非常简单的东西。
【问题讨论】：
标签： oracle entity-framework ef-code-first entity-framework-migrations