我喜欢使用 Fluent NHibernate 来构建我的数据库，并且到目前为止还没有发现任何限制阻止我前进。
然而，在我当前的项目中，我希望在产品生命周期的早期就发布到生产环境，因此随着我们的进展，数据库模式预计会有许多小的变化。
我想使用 migratordotnet。 但我的问题是：是否可以让这两个工具（或类似的工具）一起工作？
本着 DRY 的精神，我如何从 Fluent Nhibernate 中的映射中导出架构更改？ 这可能吗？
或者是否有更好的方法将模式生成留给 migratordotnet 这样的工具，而让 Fluent NHibernate 仅负责映射？ 嗯，这似乎确实是工具级别上更好的关注点分离。
干杯!
I love Fluent NHibernate for building my DBs and so far haven't found a restriction that has halted me in my tracks.
However on my current project I expect to release to production very early in the product lifecycle and hence expect there to be many small changes in the db schema as we progress.
I'd like to track these DDL amd DML changes in "migrations", using a tool like migratordotnet. But my question is: Is it possible to get these two tools (or similar tools) working together?
In the spirit of DRY, how can I derive my schema changes from my mappings in Fluent Nhibernate? Is this possible?
Or is a better approach to leave schema generation to a tool such migratordotnet and leave Fluent NHibernate with the responisibility of mapping only? Hmm, this does seem like a better seperation of concerns at a tool level.
Cheers!
发布评论
评论（4）
Gordon，
我在之前的项目中也遇到过同样的问题，我们决定专门使用 migratordotnet 进行数据库迁移，而完全跳过 SchemaUpdate。
我仍然会使用 SchemaUpdate 来实现快速原型，但一旦我认真开始该项目，我就只使用 migratordotnet。
通过将迁移设置作为每晚构建的一部分运行，一旦我们有多个人在处理一个项目，migratordotnet 就会很好地工作。
Gordon,
I've had the same question on previous projects and we've settled on using migratordotnet exclusively for our database migrations and just skipping SchemaUpdate altogether.
I will still use SchemaUpdate for quick prototypes but once I start the project in earnest I only use migratordotnet.
With the migrations setup to run as part of our Nightly builds migratordotnet works very well once we have more than one person working on a project.
我也遇到了同样的问题，我不想独立维护迁移（使用 migratordotnet）和我的映射文件。 到目前为止，我发现的唯一有用的东西是 NHibernate 的 SchemaUpdate，但它不能处理删除列或表。 对于这些类型的更改，您仍然需要手动编写迁移。 现在我倾向于使用 migratordotnet 专门用于数据库更改，而不是混合 SchemaUpdate 生成 DDL 和迁移。 但这似乎仍然容易出错，因为您可能会错误地将映射/域层更改转换为迁移。
I'm also running into this same issue, where I don't want to have to maintain migrations (using migratordotnet) and my mapping files independently. The only helpful thing I've found so far is NHibernate's SchemaUpdate, but that doesn't handle deleting columns or tables. For those types of changes you would still need to hand write a migration. Right now I'm leaning towards using migratordotnet exclusively for database changes instead of mixing SchemaUpdate generate DDL and migrations. This still seems error prone though, as you could incorrectly convert your mapping/domain layer changes to migrations.
我面临着同样的问题。 这是我当前避免 SchemaUpdate 的工作流程：
此工作流程有利于开发，因为从以下位置重建和填充数据库每次都从头开始解决数据库版本控制问题。 它还为围绕数据库和要插入的实际数据进行测试提供了良好的基础。
显然，一旦实时数据库正在运行，并且无法随意删除和重建，这将无法在生产中发挥作用。 这就是我正在做的事情：
这并不理想，需要使用商业 SQL Compare 产品。 它一直对我有用，但我想听到一些更好的想法。
I'm facing the same issue. Here is my current workflow that avoids SchemaUpdate:
This workflow is good for development, as rebuilding and populating the DB from scratch every time solves the database version control issue. It also provides a good basis for testing around your DB and the actual data you are inserting.
Obviously this is not going to work in production once a live database is running that cant be dropped and rebuild willy-nilly. This is what I'm doing:
This is not ideal and makes use of the commercial SQL Compare product. It has been working for me but I'd like to hear some better ideas.
是的——大部分。 我成功地将 FNH 和 migratordotnet 用于厚桌面客户端，并且效果很好。 我必须修改它的两件事：
允许将 sql 连接注入 TransformationProvider（或更准确地说，SQLiteTransformationProvider）
删除对其他非 sqlite TransformationProvider 的引用，因为当我尝试将其与我的应用程序打包时，它会抛出有关无法找到 Oracle、Postgres 等的各种错误。
这是 sqlite 特定的 - 破解它以便更好地解析 sqlite create table 语句。 不幸的是，它无法处理
CREATE TABLE FOO(id INT, ..., Primary key(id))形式的创建表语句（与CREATE TABLE FOO(id INT PRIMARY) 相反KEY, ...)它确实处理）。 将此与执行列删除的方式结合起来（创建无列的新表，传输数据，删除原始表并将新表重命名为原始表），这意味着您可能会遇到非常讨厌的行为，例如表上的列删除，使您的主键列成为非主键列。Yes - mostly. I am successfully using used both FNH and migratordotnet for a thick desktop client and it works quite well. I had to modify it for two things:
To allow the sql connection to be injected into the TransformationProvider (or more accuratelly, the SQLiteTransformationProvider)
rip out the references to the other non sqlite TransformationProviders as when I tried to package it with my app it would throw various errors about being unable to find Oracle, Postgres etc.
This is sqlite specific - hack it in order to better parse sqlite create table statements. Unfortunately it is unable to handle create table statements of the form
CREATE TABLE FOO(id INT, ..., primary key(id))(as opposed toCREATE TABLE FOO(id INT PRIMARY KEY, ...)which it does handle). Combine this with the way it performs column deletes (create new table sans column, transfer data over, delete original and rename new one to original), this means you can get pretty nasty behaviour like column deletion on a table making your primary key column a non-primary key column.