迁移者（FluentMigrator）的说明？ [英] Explanation of Migrators (FluentMigrator)?

问题描述

有人能解释迁移者的概念（特别fluentmigrator）

Could someone explain the concept of Migrators (specifically fluentmigrator)?

下面是（可能混淆）事实伊夫搜集关于这个问题的：

Here are the (possibly confused) facts Ive gleaned on the subject:

• 这是个办法最初版本的方式创建，然后维护一个数据库
  更新。

• Is it a way to initially create then maintain updates for a database by way of versioning.

第一个迁移（或
数据库的最初版本）将包含所有的表，关系和属性$需要（做要么流利或使用SQL的一大块在A b $ b脚本）。

The first migration (or initial version of the database) would contain all the tables, relationships and properties required (done either fluently or using a chunk of sql in a script).

当你想推更改数据库，您将创建一个新的
迁移方法（向上或向下），东西像添加一个新表或修改字段。

When you want to push a change to a database, you would create a new migration method (Up and Down), something like add a new table or modify a field.

要部署这些迁移的一个，你会用
命令行指定包含该dll迁移过程中，
连接字符串和所需的版本。

To deploy one of these migrations, you would use a command line specifying the dll containing the migration, the connection string and the required version.

如果你有一个相当复杂的数据集模型，岂不是相当困难和耗时创造了这一切迁移定义？

If you had a rather complex set of data models, wouldn't it be rather difficult and time consuming to create a migration definition for all of that?

我知道与NHibernate /流利，你可以轻松地生成一个表数据库不必定义比模型和地图文件的其他任何东西。有没有一种方法，使与迁移此配置兼容/版本？

I know with nHibernate/fluent you can easily generate tables for a database without having to define anything other than the models and map files. Is there a way to make this configuration compatible with the Migrator/Versioning?

在NHibernate的/流利负责生成一个数据库，我不一定需要定义每表的事情方面。它无论是通过约定或通过映射文件来完成。随着迁移者，我需要确定这种详细程度？

When nhibernate/fluent is in charge of generating a database, I do not necessarily need to define every thing aspect of the tables. Its done either via convention or via the mapping files. With the migrators I would need to define this level of detail?

推荐答案

的很多问题在这里。我会回答，重点FluentMigrator问题。

Lots of questions here. I'll answer the questions with a focus on FluentMigrator.

它是一种方法，最初创建，然后维护一个数据库$ B $更新b。通过版本控制的方式。

Is it a way to initially create then maintain updates for a database by way of versioning.

FluentMigrator是一种方法，版本控制数据库架构。每个人都以某种方式。无论是手动，使用SQL脚本，像SqlCompare或工具一个Visual Studio数据库项目。所有这些方法很容易陷入困境。这是很容易发布新版本时，犯了一个错误，并导致系统崩溃。迁移是一种更好的方式来处理这个问题。

FluentMigrator is a way to version control your database schema. Everyone does it in some way. Either manually, with sql scripts, with a tool like SqlCompare or a Visual Studio Database project. All these methods are easy to mess up. It is so easy to make a mistake when releasing a new version and cause the system to crash. Migrations is a better way to handle this.

FluentMigrator允许您定义更改架构的代码，这通常是在你的源代码控制检查与其他代码变化。这意味着你可以说你的系统版本1.XX应具备数据库的123版本。这意味着，如果你回滚你的代码到以前的版本，你也知道回滚到还有什么版本的数据库。

FluentMigrator allows you to define a change to the schema as code and this is usually checked in to your source control with the other code changes. Meaning that you can say version 1.XX of your system should have version 123 of the database. It means if you roll back your code to the previous version you also know what version of the database to rollback to as well.

这既可以用来创建数据库架构从一开始或架构的版本控制现有数据库启动。

It can be used both to create the database schema from the beginning or to start with version control of the schema for an existing database.

迁移是描述一个改变你的数据库模式的方法。 FluentMigrator创建一个VERSIONINFO表和存储后是一直应用迁移的唯一标识（版本号）。

A Migration is a way to describe a change to your database schema. FluentMigrator creates a VersionInfo table and stores the unique id (version number) of the Migration after is has been applied.

例如，如果我有两个迁移一个用ID 1，一个ID为2。如果我再执行第一迁移则id 1将被存储在VERSIONINFO表我可以看看那里知道数据库的版本1和版本2尚未应用。

For example, if I have two Migrations one with Id 1 and one with Id 2. If then I execute the first Migration then Id 1 will be stored in the VersionInfo table and I can look there and know that the version of the database is 1 and that version 2 has not been applied yet.

如果能够知道数据库模式是哪个版本从测试非常有用力推的变化时，生产或者如果你有在生产数据库的多个副本。例如，我有办事处客户世界各地，每个办公室都有自己的数据库副本，所有的人都在不同的版本。如果不知道数据库版本，将是非常困难的安全更新。

Being able to know which version the database schema is very useful when pushing changes from Test to Production or if you have multiple copies of the database in Production. For example, I have a customer with offices all around the world and each office has their own copy of the database and all of them are on different versions. Without knowing the database version it would be very difficult to update them safely.

大多数时候我并不需要实际看在VERSIONINFO表，FluentMigrator这种自动处理。它装配与迁移到VERSIONINFO表进行比较，并计算出它的变化还没有被应用，然后执行这些。

Most of the time I do not need to actually look in the VersionInfo table, FluentMigrator handles this automatically. It compares the assembly with Migrations to the VersionInfo table and figures out which changes have not been applied yet and then executes those.

第一个迁移（或数据库的最初版本）将包含
所需的所有表，关系和属性（做或者
流利或者使用脚本的SQL的块）。

The first migration (or initial version of the database) would contain all the tables, relationships and properties required (done either fluently or using a chunk of sql in a script).

的出发点是给你。你可以有一个第一次迁移的是，你从当前数据库生成的SQL脚本。你可以也可以使用的contrib项目之一，如 FluentMigrator.T4 以产生良好移民。或者您也可以决定，现有数据库的出发点并保存它的一个副本，以便能够将其恢复为版本1。

The starting point is up to you. You can have a first migration that is an sql script that you have generated from the current database. You could could also use one of the contrib projects like FluentMigrator.T4 to generate a Fluent Migration. Or you could just decide that the existing database is the starting point and save a copy of it to be able to restore it as version 1.

我已经介绍FluentMigrator到很多遗留数据库没有什么大问题。

I have introduced FluentMigrator to a lot of legacy databases without any major problems.

当你想推更改数据库，您将创建一个新的
迁移方法（向上或向下），像添加一个新表或
修改字段。

When you want to push a change to a database, you would create a new migration method (Up and Down), something like add a new table or modify a field.

是的，向上用于应用在指定迁移的变化和向下滚回来。因此，最多可以创建一个表和下可能会删除表。

Yes, Up is used to apply the change specified in the Migration and Down rolls it back. So Up could be to create a table and Down could be to drop the table.

要部署这些迁移的一个，你会用命令行
指定包含迁移，连接字符串和
所需版本的DLL。

To deploy one of these migrations, you would use a command line specifying the dll containing the migration, the connection string and the required version.

有3 亚军的可用于执行迁移。命令行亚军的任务南特和MSBuild任务。通常有作为构建脚本的一部分执行。

There are three runners available to execute migrations. The command line runner, the Nant task and the MSBuild task. There are usually executed as part of a build script.

MigrationRunner类也可以在代码中使用。你可以这样做，如果你想建立自己的亚军或者如果你有其他需求（如动态建立的数据库或自动，如果添加了新的迁移更新数据库。）

The MigrationRunner class can also be used in code. You might do this if you wanted to build your own runner or if you have other needs (like building databases dynamically or automatically updating the database if a new migration is added.)

如果你有一个相当复杂的数据模型，岂不是相当
困难和耗时创造的所有
迁移定义？

If you had a rather complex set of data models, wouldn't it be rather difficult and time consuming to create a migration definition for all of that?

我大多已经回答了这个。它通常是很容易生成一个数据库的SQL脚本。对于SQL Server需要不到一分钟来生成脚本，甚至对于大型数据库。该脚本可以保存在.sql文件和使用Execute.EmbeddedSqlScript表达式中第一个迁移执行。它的工作原理一种享受。

I have mostly answered this already. It is usually quite easy to generate an sql script for a database. For Sql Server it takes less than a minute to generate the script even for large databases. This script can be saved in a .sql file and executed as the first migration using the Execute.EmbeddedSqlScript expression. It works a treat.

我知道与NHibernate /流利，你可以很容易地生成一个
数据库表不必定义什么比模型和
地图文件等。有没有一种方法，使与
的迁移/版本？

I know with nHibernate/fluent you can easily generate tables for a database without having to define anything other than the models and map files. Is there a way to make this configuration compatible with the Migrator/Versioning?

目前，此配置不兼容，有没有这样的整合并在实践中我，至少，不要错过哦。有关于连接流利NHibernate和FluentMigrator，但是这将是一个大量的工作进行了一些讨论。它将使支架产生的变化像EF代码优先迁移做模型。这不是上不过此刻的路线图。

At the moment, there is no such integration and in practise I, at least, don't miss it. There was some discussion about connecting Fluent NHibernate and FluentMigrator but it would be a lot of work. It would enable scaffolding to generate changes to the model like EF Code First migrations do. It's not on the roadmap at the moment however.

在NHibernate的/流利负责生成一个数据库，我不
不一定需要定义表的每一件事情方面。无论是通过约定或通过映射文件对其做
。随着迁移者我
需要定义这种详细程度？

When nhibernate/fluent is in charge of generating a database, I do not necessarily need to define every thing aspect of the tables. Its done either via convention or via the mapping files. With the migrators I would need to define this level of detail?

是的，你需要在该级别定义的细节。 FluentMigrators迁移对定义将被转换为SQL架构更改的DSL（自己的小语）。您可以使用Execute.Sql表达直接写sql为好。实体框架迁移有那种有优点也有缺点的整合。

Yes, you would need to define at that level of detail. FluentMigrators' migrations are a DSL (own little language) for defining schema changes that are translated to sql. You can write sql directly as well using the Execute.Sql expression. Entity Frameworks migrations have that sort of integration which has both advantages and disadvantages.

检查出的维基或的教程这里之一， 这里（第1部分）或here （部分2），以获得更多帮助入门。

Check out the wiki or one of the tutorials here, here (part 1) or here (part 2) for more help getting started.

这篇关于迁移者（FluentMigrator）的说明？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！