命令列表
rake db:migrate 命令作用:将所有未实施的迁移任务都实施到目标数据库上。
rake db:migrate VERSION=20080906120000 命令作用:撤销迁移任务到指定版本 迁移版本信息可以在所创建库(如elvuel_deployment数据库)下schema_info表中查看到相关记录信息。
rake db:migrate VERSION=0 命令作用:将数据库返回到最初状态(即,只有schema_migrations表,其他表都删除)
rake db:migrate VERBOSE=false 命令作用:屏蔽migration的输出
rake db:rollback 命令作用:回滚到最近的一次migration执行的状态
rake db:rollback STEP=3 命令作用:回滚最近的3次的迁移任务
一个在开发阶段很常用的命令redo: rake db:migrate:redo 命令作用:重做迁移
rake db:migrate:redo STEP=3 rake db:migrate:down VERSION=9999999999
================================================ agile with rails ================================================ Rails鼓励敏捷,迭代的开发风格。我们不会第一次就期望得到正确的东西。相反我们会写测试,并与客户沟通以加强我们对事物的理解。 要做到这些,我们就需要大量的实践工作。我们写测试来帮助规划我们接口,以便我们能安全地进行修改,我们对应用程序源文件使用版本控制,允许我们回说溯错误,并可监视我们每天的改动。 但对于应用程序修改的另一方面来说,我们不能直接使用版本控制来管理。它就是我们在开发过程中,对应用程序中数据库schema的管理:我们添加一个表,重命名列名称等等。数据库的修改需要应用程序的代码。 很久以来,这一直是个问题。开发者(或数据库管理员)使用schema进行修改。但是,如果应用程序代码可以回溯到一个先前版本,但数据库schema的修改却不是同步的。因为数据库本身没有版本信息。 不久前,开发者以提出了多种解决这个问题的途径。一个schema保持了数据库定义语言(DDL),而DDL在版本控制下以源代码方式定义了schema。无论何时只要你修改了schema,你通过编辑这个文件来反映做出的修改。那么你会中止你的development数据库,并重新从你写的DDL中创建schema。如果你需要回溯到一周之前的话,那么你就会按这些步骤来检查应用程序代码和DDL:当你重新从DDL创建schema时,你的数据库会得到及时的回溯。 除了…..因为你每次应用DDL时,你都会中止数据库,你会丢失放在development数据库内的数据。如果我们能将数据库从版本x迁移到y就更好了?不错,Rails的migration迁移就可让你做到点。 让我们先在抽象层上看看migration迁移。假设我们有个存储定单数据的order表。有一天,我们的客户要求我们为每个定单上添加用户的邮件地址。这就包括了对应用程序代码数据库shema的修改。要处理它,我们创建了一个数据库migration迁移,在其内描述“给orders表添加一个e-mail字段”。这个migration迁移放在一个单独的文件内。我们将其与另外的应用程序文件一起放在版本控制下。然后我们对数据库使用这个migration迁移,结果列被添加到现有的orders表内。 如何正确地为数据库完成一个migration迁移呢?每次migration迁移都会有一个序号与其关联。这些序号从1开始---每个新的migration迁移都会得到下一个有效序号。Rails会记住应用给数据库migration迁移的最后一个序号。那么你会问,何时应用新的migration迁移来更新schema,它将数据库schema的序号与有效的migragion迁移序号进行比较。如果它发现migration迁移的序号大于数据库的schema,它就会应用migration迁移。 但是我们如何回溯一个先前版本的schema呢?我们通过让每个migration迁移都是可回溯的来做到这一点。每个migration迁移实例上都包含两个指令集。一套告诉Rails在应用migration迁移时对数据库做出什么修改,另一套则告诉Rails如何回溯这些修改。在orders表例子中,是添加e-mail列到表与移除列的回溯两部分。现在,要回溯一个schema,我们只要简单地告诉Rails我们需要数据库schema序号就可以了。如果当前数据库schema有个比目标序号更高的序号,则Rails会接受带有数据库当前序号的migration迁移,并使用它进行回溯。这会从schema中移除migration迁移的修改,并降低数据库的序号。它会反复执行此过程直到得到期望的数据库版本。
16.1 创建与运行Migration迁移
Migration迁移是应用程序db/migrate目录下的一个简单的Ruby源文件。每个migration迁移文件的名字(默认地)以三个数字和一个下划线开头。这些数字是migration迁移的关键,因为它们定义了应用哪个migration迁移的次序,它们各个migration迁移的版本号。 Depot应用程序的db/migrate目录看起像这样: depot> ls db/migrate 001_create_products.rb 005_create_orders.rb 002_add_price.rb 006_create_line_items.rb 003_add_test_data.rb 007_create_users.rb 004_add_sessions.rb 虽然你可以通过手工来创建这些migration迁移文件,但使用一个生成器会更容易(这会减少错误)。就像在创建Depot应用程序时看到的,实际上有两种用于创建migration迁移文件的生成器: 1、模型生成器(model generator) 创建的migration迁移,用于创建与模型关联的表(只要你不使用skip-migrations选项)。如下面例子所示,创建了名为discount的模型,同时也创建了名为add_create_discounts.rb的migration迁移。 depot> ruby script/generate model discount exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/discount.rb create test/unit/discount_test.rb create test/fixtures/discounts.yml exists db/migrate create db/migrate/014_create_discounts.rb 2、你也可以用生成器只创建migration迁移本身。 depot> script/generate migration add_price_column exists db/migrate create db/migrate/015_add_price_column.rb 稍后,我们会从Migration的解剖图开始,我们会看到migration迁移文件是什么。但现在,我们还是先看看如何运行migration迁移。 一、Running Migrations 使用Rake的db:migrate任务来运行migration迁移。 depot> rake db:migrate 下面看看发生了什么,让我们深入到Rails的内部。 在Rails数据库内部,migration迁移代码管理一个名为schema_info的表。该表只有一个列,名为version,并且它只有一行记录。此schema_info表被用于记住当前的数据库版本。 当运行rake db:migrate时,任务首先会查看schema_info表。如果该表不存在,它将创建一个并且生成版本号为0的记录。若该表存在,则从表中读取版本号。 然后migration迁移代码查看db/migrate目录下的所有migration迁移文件。如果有序号(文件名的前导数字)大于当前数据库的版本号,那么会为数据库依次应用每个migration迁移文件。在最后一个migration迁移文件应用后,schema_info表的版本号会被更新为该文件的序号。 如果我们这一序号上再次运行migration迁移,则不会发生任何事。因为数据库内版本号已等于最高序号migration迁移文件的序号,所以不会应用任何migration迁移文件。 但是,如果我们随后创建了一个新的migration迁移文件,它就会有个大于数据库版本号的序号。如果我们随后运行该migration,则这个新的migration迁移文件会被运行。 你可以通过给rake db:migrate命令行应用VERSION=参数来为数据库强制指定一个特定的版本号。如果你给出的版本号高于数据库的版本号,则会以运行数据库版本的migration开始,以你指定的版本migration结束。 但是,如果命令行的版本号小于当前数据库的版本号,那么会发生不同的事情。在这些情形下,Rails查找与数据库版本匹配的migration迁移文件,并且回溯它。然后它降低版本号,查找匹配文件,再回溯它,等等,直到版本号匹配你在命令行上指定版本号。也就是说,migration迁移被向后应用以回溯schema回到你指定版本。
16.2 Migration解剖图 你通过创建Rails类ActiveRecord::Migration的子类来写一个migration迁移。你创建的类至少应该包含两个类方法up()和down()。 class SomeMeaningfulname < ActiveRecord::Migration def self.up # ... end def self.down # ... end end 在down()方法回溯修改的同时,up()方法有责任为这个migration迁移应用schema修改。让我们做的更具体些。这儿是个migration迁移,它为orders表添加一个e_mails列。 class AddEmailColumnToOrders < ActiveRecord::Migration def self.up add_column :orders, :e_mail, :string end def self.down remove_column :orders, :e_mail end end 看看down()方法的回溯是如何影响到up()方法的。
一、Column Types (列类型) 传递给add_column的第三个参数指定了数据库列的类型。 在前面例子中,我们指定e_mail列是 :string 类型。但这么做意味着什么呢?典型地数据库没有 :string 列类型。 回忆一下,Rails试图让你的应用程序不依赖于支持它运行的数据库:你可以开发使用MySQL,如果愿意也可开使用Postgres数据库的应用用程序。但不同的数据库为列类型使用了不同的名字。如果你在migration迁移中使用了一个MySQL列类型,那么这个migration迁移对Postgres数据库就不会工作。所以Rails migration迁移将你从基础数据库类型系统隔离开而使用逻辑类型。如果你迁移一个MySQL数据库,那么 :string 类型将创建一个varchar(255)类型的列。在Postgres上,同样的迁移会添加一个varing(255)类型的列。 由migration迁移支持的类型是: :binary,:boolean,:date,:datetime,:float,:integer,:string,:text,:time,和:timestamp。256页的图16-1显示了在Rails内数据库适配器对这些类型的缺省映射。使用这个图,你在一个migration迁移内,用 :integer声明的列在MySQL内基于类型int(11),在Oracle内基于number(38)来工作。 当在一个migration迁移内定义一个列时,你可指定三个选项。每个选项由key=>value对给出。 1、:null => true or false 如果为 true,则基础列被添加一个不能为null的约束(如果数据库支持的话)。 2、:limit => size 设置字段尺寸的限制。这基本上出现在用string创建数据库的列时。 3、:default => value 为列设置缺省值。如果你传递一个Ruby值(或Ruby表达式),那个值会变成列的默认值。对一些数据库,你也可以传递一个包含数据库指定表达式的字符串。 例如,指定 add_column :orders, :placed_at, :datetime, :default => Time.now 将在migration迁移运行时,设置列的默认值为日期和时间, 指定add_column :orders, :placed_at, :datetime, :default => "now()" 会设置MySQL now()函数为默认值,因此当前日期时间将被插入到任何新的行内。后面的语法很明显是数据库指定的。 下面是一些使用migration迁移类型和选项的例子: add_column :orders, :name, :string, :limit => 100, :null => false add_column :orders, :age, :integer add_column :orders, :ship_class, :string, :limit => 15, :default => 'priority'
二、Renaming Columns (重命名列) 在我们重构代码时,通常会修改我们变量的名字,以让它们更有意义。Rails的migration迁移也允许我们对数据库的列名字这样做。例如,在添加了一周之后,我们可能认为e_mail并不是那个新列最好的名字。我们可以创建一个migration迁移来重命名它。 class RenameEmailColumn < ActiveRecord::Migration def self.up rename_column :orders, :e_mail, :customer_email end def self.down rename_column :orders, :customer_email, :e_mail end end 注意重命名列并不会删除任何与该列相关的数据。但是要小心并不是所有的数据库适配器都支持重命名的。
三、Changing Columns (更改列) 有时候你可能需要更改列的类型,或改变与列关联的选项。它与你使用add_column的方式一样,但指定是一个现有列的名字。我们假设order类型列当前是个integer,但我们需要更改它为string。我们想保持现有数据,所以一个123的order类型数据将变成字符串”123”。随后,我们就可使用非整数值如”new”和”existing”。 Changing from an integer column to a string is easy: def self.up change_column :orders, :order_type, :string, :null => false end 但是,向相反方向的转换却是个问题。我们可能会试着这样写down() migration迁移: def self.down change_column :orders, :order_type, :integer end 但是如果我们的应用程序已在这个列中存储了像”new”这样的数据,down()方法将会丢失数据 --- “new”不能被转换成一个整数。如果这是可接受的,那么migration迁移就接受它。然而,如果我们想创建一个单向的migration迁移 --- 那么它就是不可逆转的 --- 你会中止向下的migration迁移。在这种情况下,Rails提供了一个你可以抛出的特殊异常。 class ChangeOrderTypeToString < ActiveRecord::Migration def self.up change_column :orders, :order_type, :string, :null => false end def self.down raise ActiveRecord::IrreversibleMigration end end |
Migration
最新推荐文章于 2024-09-05 10:00:22 发布