您的位置:首页 > 编程语言 > Ruby

guides.rubyonrails.org 读书笔记(四)

2011-03-04 15:47 441 查看

Migrations

Migrations also allow you to describe these transformations using Ruby.
The great thing about this is that (like most of Active Record’s
functionality) it is database independent

1.1 Migrations are Classes

On databases that support transactions with statements that change the
schema (such as PostgreSQL or SQLite3), migrations are wrapped in a
transaction. If the database does not support this (for example MySQL)
then when a migration fails the parts of it that succeeded will not be
rolled back.

You will have to unpick the changes that were made by hand.

1.2 What’s in a Name

The name of the migration class (CamelCased version) should match the latter part of the file name. For example 20080906120000_create_products.rb
should define CreateProducts
and 20080906120001_add_details_to_products.rb
should define AddDetailsToProducts
. If you do feel the need to change the file name then you have to
update the name of the class inside or Rails will complain about a missing class.

Of course this is no substitution for communication within the team. For
example, if Alice’s migration removed a table that Bob’s migration
assumed to exist, then trouble would certainly strike.

1.3 Changing Migrations

In general editing existing migrations is not a good idea: you will be
creating extra work for yourself and your co-workers and cause major
headaches if the existing version of the migration has already been run
on production machines. Instead you should write a new migration that
performs the changes you require. Editing a freshly generated migration
that has not yet been committed to source control (or more generally
which has not been propagated beyond your development machine) is
relatively harmless. Just use some common sense.

2 Creating a Migration

2.1 Creating a Model

The model and scaffold generators will create migrations appropriate for adding a new model.

rails generate model Product name:string description:text


2.2 Creating a Standalone Migration

If you are creating migrations for other purposes (for example to add a
column to an existing table) then you can use the migration generator:

(1) empty table

rails generate migration AddPartNumberToProducts


(2)
rails generate migration AddPartNumberToProducts part_number:string


If the migration name is of the form “AddXXXToYYY” or “RemoveXXXFromYYY”
and is followed by a list of column names and types then a migration
containing the appropriate add_column
and remove_column
statements will be created.

(3) rails generate migration AddDetailsToProducts part_number:string price:decimal

3. Writing a Migration

3.1 Creating a Table

By default create_table
will create a primary key called id
. You can change the name of the primary key with the :primary_key
option (don’t forget to update the corresponding model) or if you don’t want a primary key at all (for example for a HABTM
join table) you can pass :id => false
. If you need to pass database specific options you can place an SQL
fragment in the :options
option.

3.2 Changing Tables

3.3 Special Helpers

3.4 Writing Your down
Method

4 Running Migrations

(1) rake db:migrate VERSION=20080906120000


If this is greater than the current version (i.e. it is migrating upwards) this will run the up
method on all migrations up to and including 20080906120000, if migrating downwards this will run the down
method on all the migrations down to, but not including
, 20080906120000.

(2)
rake db:rollback STEP=3

will run the down
method from the last 3 migrations.

(3)

The db:migrate:redo
task is a shortcut for doing a rollback and then migrating back up again. As with the db:rollback
task you can use the STEP
parameter if you need to go more than one version back, for example

5 Using Models in Your Migrations

Frequently I just want to update rows in the database without writing out the SQL
by hand: I’m not using anything specific to the model. One pattern for
this is to define a copy of the model inside the migration itself.

隔离性能?进一步学习

5.1 Dealing with Changing Models

For performance reasons information about the columns a model has is cached.

6.

There are two ways to dump the schema. This is set in config/application.rb
by the config.active_record.schema_format
setting, which may be either :sql
or :ruby
.

7. Active Record and Referential Integrity

The Active Record way claims that intelligence belongs in your
models, not in the database. As such, features such as triggers or
foreign key constraints, which push some of that intelligence back into
the database, are not heavily used.

Validations such as validates_uniqueness_of
are one way in which models
can enforce data integrity.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: