以下是我收集到的(可能是困惑的)事实：
>它是最初创建的方式,然后维护数据库的更新
通过版本控制.
>第一次迁移(或初始版本
数据库)将包含所有表,关系和属性
需要(流畅地完成或在脚本中使用大量的sql).
>当您要将更改推送到数据库时,您将创建一个新的
迁移方法(向上和向下),像添加新表或修改字段.
>要部署其中一个迁移,您将使用
指定包含迁移的dll的命令行,
连接字符串和所需的版本.
如果您有一套相当复杂的数据模型,为所有这些创建迁移定义不是相当困难和耗时吗？
我用nHibernate /流畅知道,您可以轻松地为数据库生成表,而无需定义除模型和映射文件之外的任何内容.有没有办法使此配置与Migrator / Versioning兼容？
当nhibernate / fluent负责生成数据库时,我不一定需要定义表的每一个方面.它通过惯例或通过映射文件完成.与迁移者我将需要定义这个级别的细节？
解决方法
Is it a way to initially create then maintain updates for a database
by way of versioning.
FluentMigrator是一种版本控制数据库模式的方式.每个人都以某种方式做到这一点.手动使用sql脚本,使用sqlCompare或Visual Studio数据库项目等工具.所有这些方法都很容易搞砸.在发布新版本并导致系统崩溃时,很容易犯错误.迁移是更好的方式来处理这个问题.
FluentMigrator允许您将模式的更改定义为代码,通常会使用其他代码更改来检查源代码控制.意味着你可以说系统的版本1.XX应该有版本123的数据库.这意味着如果您将代码回滚到以前的版本,您还可以知道要回滚的数据库的哪个版本.
它可以用于从头开始创建数据库模式,也可以从现有数据库的模式的版本控制开始.
迁移是描述数据库模式变化的一种方式. FluentMigrator创建一个VersionInfo表,并存储适用于迁移的唯一ID(版本号).
例如,如果我有两个迁移,一个具有Id 1,一个具有Id 2.如果然后我执行第一个Migration,那么Id 1将被存储在VersionInfo表中,我可以看到那里,知道数据库的版本是1该版本2尚未应用.
能够知道哪个版本的数据库模式在从“测试”到“生产”推送更改时非常有用,或者在“生产”中有多个数据库副本.例如,我有一个在世界各地设有办事处的客户,每个办公室都有自己的数据库副本,所有这些都在不同的版本上.不知道数据库版本,将很难安全地更新它们.
大多数时候,我不需要实际查看VersionInfo表,FluentMigrator会自动处理.它将汇编与迁移比较到VersionInfo表,并确定哪些更改尚未应用,然后执行那些.
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脚本.您还可以使用其中一个诸如FluentMigrator.T4的contrib项目来生成流畅的迁移.或者您可以仅仅决定现有的数据库是起始点,并保存其副本以便将其还原为版本1.
我已经将FluentMigrator引入了许多遗留数据库,没有任何重大问题.
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.
是的,Up用于应用在“迁移”和“Down”中指定的更改.所以可以创建一个表,而Down可以放下表.
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.
有三个runners可用于执行迁移.命令行跑步者,Nant任务和MSBuild任务.通常作为构建脚本的一部分执行.
MigrationRunner类也可以在代码中使用.如果您想要构建自己的运行程序或者有其他需求(例如,如果添加了新的迁移,动态构建数据库或自动更新数据库),则可以执行此操作.
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 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?
目前,没有这样的一体化,实际上我至少不要错过.有一些关于连接Fluent NHibernate和FluentMigrator的讨论,但这将是很多工作.它将使脚手架能够生成模型的更改,如EF Code First迁移.目前还没有在路线图上.
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的迁移是一种DSL(自己的小语言),用于定义转换为sql的模式更改.您也可以使用Execute.sql表达式直接编写sql.实体框架迁移具有这样的一体化,既有优缺点.
原文地址：https://www.jb51.cc/csharp/95237.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
