16

我喜欢 Fluent NHibernate 来构建我的数据库，并且到目前为止还没有发现任何阻碍我前进的限制。

然而，在我目前的项目中，我希望在产品生命周期的早期发布到生产环境，因此预计随着我们的进展，db 模式会有许多小的变化。

我想使用migratordotnet之类的工具在“迁移”中跟踪这些 DDL 和 DML 更改。但我的问题是：是否有可能让这两个工具（或类似工具）一起工作？

本着 DRY 的精神，我如何从 Fluent Nhibernate 中的映射中导出架构更改？这可能吗？

或者是将模式生成留给诸如 migratordotnet 之类的工具并让 Fluent NHibernate 只负责映射的更好方法？嗯，这似乎是在工具级别更好地分离关注点。

干杯!

4

4 回答 4

7

戈登，

我在以前的项目中也有同样的问题，我们已经决定将 migratordotnet 专门用于我们的数据库迁移，并且完全跳过 SchemaUpdate。

我仍然会使用 SchemaUpdate 来快速制作原型，但是一旦我认真开始这个项目，我只会使用 migratordotnet。

随着迁移设置作为我们 Nightly 构建的一部分运行，一旦我们有多个人在一个项目上工作，migratordotnet 就会很好地工作。

于 2009-06-03T20:07:14.183 回答
2

我也遇到了同样的问题，我不想独立维护迁移（使用 migratordotnet）和我的映射文件。到目前为止，我发现的唯一有用的东西是 NHibernate 的 SchemaUpdate，但它不能处理删除列或表。对于这些类型的更改，您仍然需要手写迁移。现在我倾向于使用 migratordotnet 专门用于数据库更改，而不是混合使用 SchemaUpdate 生成 DDL 和迁移。不过，这似乎仍然容易出错，因为您可能会错误地将映射/域层更改转换为迁移。

于 2009-06-03T15:00:17.190 回答
1

我面临同样的问题。这是我当前避免 SchemaUpdate 的工作流程：

  • 从头开始构建数据库（如果进行了任何更改）
  • 将所有参考数据保存在电子表格中
  • 通过特殊命令行“dataloader”项目重新加载所有数据

此工作流程有利于开发，因为每次都从头开始重建和填充数据库可以解决数据库版本控制问题。它还为围绕您的数据库和您插入的实际数据进行测试提供了良好的基础。

显然，一旦运行的实时数据库无法删除并随意重建，这将无法在生产中工作。这就是我正在做的事情：

  • 开发周期完成后，我会克隆生产数据库。Prod 数据库在升级期间设置为只读（对我的应用程序来说还可以……不确定更多时间关键的应用程序）
  • 使用 SQL Compare 将更改和数据从 dev 迁移到 prod 数据库
  • 推这个来测试。
  • 如果测试通过，则推送到生产环境。

这并不理想，并且使用了商业 SQL 比较产品。它一直对我有用，但我想听听一些更好的想法。

于 2009-12-21T17:03:49.207 回答
0

是的——主要是。我成功地将 FNH 和 migratordotnet 用于厚桌面客户端，并且效果很好。我不得不为两件事修改它：

  1. 允许将 sql 连接注入 TransformationProvider（或更准确地说是 SQLiteTransformationProvider）

  2. 删除对其他非 sqlite TransformationProviders 的引用，因为当我尝试将它与我的应用程序打包时，它会引发各种关于无法找到 Oracle、Postgres 等的错误。

  3. 这是特定于 sqlite 的 - 破解它以便更好地解析 sqlite create table 语句。不幸的是，它无法处理表单的创建表语句CREATE TABLE FOO(id INT, ..., primary key(id))（与CREATE TABLE FOO(id INT PRIMARY KEY, ...)它处理的相反）。结合它执行列删除的方式（创建新表无列，传输数据，删除原始并将新的重命名为原始），这意味着您可以获得非常讨厌的行为，例如在表上删除列，使您的主键列成为非主键列。

于 2010-08-30T12:34:32.700 回答