Rails Migrations Ⅲ

最新推荐文章于 2024-10-08 15:41:48 发布

weixin_34004750

最新推荐文章于 2024-10-08 15:41:48 发布

阅读量86

点赞数

文章标签：数据库 ruby

本文链接：https://blog.csdn.net/weixin_34004750/article/details/85153118

版权

16.5 Advanced Migrations --- 高级的 migration 迁移

大多数Rails开发者使用migration迁移的基本功能来创建和管理数据库schema。但是，常常只需在向前一小步，就会让migration迁移更有用。本节讨论一些高级migration迁移用法。

一、Using Native SQL --- 使用原生SQL

Migration迁移给你一个不依赖数据库管理应用程序schema的方式。但是，如果migration迁移没有包含你需要的，能够完成你需要完成工作的方法，你将需要编写指定的数据库代码。要这样做，可使用execute()方法。

我常用的migration迁移例子是给子表添加一个外键约束。在创建line_items表时我们见过它。

class CreateLineItems < ActiveRecord::Migration

def self.up

create_table :line_items do |t|

t.column :product_id, :integer, :null => false

t.column :order_id, :integer, :null => false

t.column :quantity, :integer, :null => false

t.column :total_price, :integer, :null => false

end

execute "alter table line_items add constraint fk_line_item_products

foreign key (product_id) references products(id)"

execute "alter table line_items add constraint fk_line_item_orders

foreign key (order_id) references orders(id)"

end

def self.down

drop_table :line_items

end

When you use execute( ), you might well be tying your migration to a specific database engine: SQL you pass as a parameter to execute( ) uses your database’s native syntax.

The execute( ) method takes an optional second parameter. This is prepended to the log message generated when the SQL is executed.

二、Extending Migrations --- 扩展Migration迁移

如果你观察前一节的line item 迁移，你可能对两个execute()语句的重复部分感到奇怪。将外键的创建包含到helper方法内是很好的抽象。

我们可以通过添加一个方法来做到，如下面的migration迁移源文件。

def self.foreign_key(from_table, from_column, to_table)

constraint_name = "fk_#{from_table}_#{from_column}"

execute %{alter table #{from_table}

add constraint #{constraint_name}

foreign key (#{from_column})

references #{to_table}(id)}

end

(self. 是必须的，因为migration迁移是做为一个类方法运行的，所以我们需要在这个上下文环境内调用foreign_key()。)

在up()迁移内，我们可以使用下面来调用这个新方法

def self.up

create_table ...

end

foreign_key(:line_items, :product_id, :products)

foreign_key(:line_items, :order_id, :orders)

end

虽然，我们可能希望更进一步，使我们的foreign_key()方法能对所有的migration迁移有效。要做到这，可在应用程序的lib目录内创建一个模型，并添加foreigh_key()方法。但这次，让它做为一个常规的实例方法，而不是类方法。

module MigrationHelpers

def foreign_key(from_table, from_column, to_table)

constraint_name = "fk_#{from_table}_#{from_column}"

execute %{alter table #{from_table}

add constraint #{constraint_name}

foreign key (#{from_column})

references #{to_table}(id)}

end

现在，你可以添加下面行到你的migration迁移文件顶部，以在任何migration迁移内包括它。

require "migration_helpers"

class CreateLineItems < ActiveRecord::Migration

extend MigrationHelpers

require行会在migration迁移代码内产生模型定义，并且extend行会添加MigrationHelpers模板的方法做为migration迁移内的类方法。你可以使用这种技术来开发，共享任何数量的migration迁移helper方法。

(并且，如果你想让你的生活更轻松，有些人写了一个插件，它自动管理添加外键约束。)

16.6 When Migrations Go Bad

Migration迁移经受着一系列问题。更新数据库schema的基础DDL语句不是事务的。这不是Rails的错误 --- 数据库对创建表，更新表和其它DDL语句不支持回滚。

让我们观察试图给数据库添加两个表的一个migration迁移。

class ExampleMigration < ActiveRecord::Migration

def self.up

create_table :one do ...

end

create_table :two do ...

end

def self.down

drop_table :two

drop_table :one

end

在常规的事件过程中，up()方法添加表one和two，并且用drop()方法移除它们。

但如果在创建第二个表出现了问题时会发生什么呢？最终数据库会包含表one，但不包含表two。我们可以在migration迁移内修改这个问题，但现在我们却不能应用它 --- 如果我们试着用了，它将失败，因为表one已经存在了。

我们可以试试回滚migration迁移，但这没有用：因为原有的migration迁移失败了，数据库内的schema版本并没有更新，所以Rails不会尝试进行回滚。

从这点上说，你得浪费些时间用手工更改schema信息并删除表one。但或许不值得这样做。在这些情况下，我们的建议是简单地删除整个数据库，然后再重建它，并应用migration迁移来生成回溯数据。你不会丢失任何东西，并且你会知道你有个一致的shema。

16.7 Schema Manipulation Outside Migrations

本章描述的所有migration迁移方法也可有效地做为活动记录的connection对象方法，并且可以在Rails应用程序的模型，视图，控制器内访问。

For example, you might have discovered that a particular long-running report runs a lot faster if the orders table has an index on the city column. However, that index isn’t needed during day-to-day running of the application, and tests have shown that maintaining it slows the application appreciably.

让我们写个方法，它创建索引，运行一个代码块，然后删除索引。它可是模型内的一个私有方法，或者是一个库内实现。

def run_with_index(column)

connection.add_index(:orders, column)

begin

yield

ensure

remove_index(:orders, column)

end

The statistics gathering method in the model can use this as follows:

def get_city_statistics

run_with_index(:city) do

# .. calculate stats

end

16.8 Managing Migrations

有些东西会降低migration迁移的作用。随着时间推移，你的schema定义将会分散到大量的单个migration迁移文件内，这么多的文件会影响你schema内每个表的定义。当这发生时，它会变得很难准确查看包含的每个表。这儿有一些让生活更轻松的建议。

有些team不能用于单独的migration迁移以获取所有的schema版本。相反，它们保持migration迁移文件在每个表内，其它migration迁移文件加载development数据到这些表中。当它们需要修改schema时(比如说给表添加列)，为那个表编辑现有的migration迁移文件。然后，它们清除并重新创建数据库，并重复应用所有的migration迁移。依据这个途径，它们总是可以在那个表的migration迁移文件内看到每个表的整个定义。

To make this work in practice, each member of the team needs to keep an eye on the files that are modified when updating their local source code from the project’s repository. When a migration file changes, it’s a sign that the database schema needs to be recreated.

Although it seems like this scheme flies against the spirit of migrations, it actually works well in practice.

使用migration迁移的另一种途径是我们本章前面描述的，为schema的每次修改创建一个新的migration。为了保持对schema发展的跟踪，你可以使用annotate_models插件。在运行时，这个插件观察当前的schema并添加对每个表的描述在用于那个表的模型顶部。