1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00

Use a deliberately-invalid migration version in all doc examples

If we use a real version, at best that'll be an onerous update required
for each release; at worst, it will encourage users to write new
migrations against an older version than they're using.

The other option would be to leave these bare, without any version
specifier. But as that's just a variant spelling of "4.2", it would seem
to raise the same concerns as above.
This commit is contained in:
Matthew Draper 2015-12-06 06:29:19 +10:30
parent 6940dc860c
commit c0af95e0ab
9 changed files with 54 additions and 54 deletions

View file

@ -138,7 +138,7 @@ This would also define the following accessors: <tt>Product#name</tt> and
* Database agnostic schema management with Migrations.
class AddSystemSettings < ActiveRecord::Migration
class AddSystemSettings < ActiveRecord::Migration[0.0]
def up
create_table :system_settings do |t|
t.string :name

View file

@ -1639,7 +1639,7 @@ module ActiveRecord
# The join table should not have a primary key or a model associated with it. You must manually generate the
# join table with a migration such as this:
#
# class CreateDevelopersProjectsJoinTable < ActiveRecord::Migration
# class CreateDevelopersProjectsJoinTable < ActiveRecord::Migration[0.0]
# def change
# create_join_table :developers, :projects
# end

View file

@ -190,7 +190,7 @@ module ActiveRecord
# Inside migration files, the +t+ object in {create_table}[rdoc-ref:SchemaStatements#create_table]
# is actually of this type:
#
# class SomeMigration < ActiveRecord::Migration
# class SomeMigration < ActiveRecord::Migration[0.0]
# def up
# create_table :foo do |t|
# puts t.class # => "ActiveRecord::ConnectionAdapters::TableDefinition"

View file

@ -13,7 +13,7 @@ module ActiveRecord
# For example the following migration is not reversible.
# Rolling back this migration will raise an ActiveRecord::IrreversibleMigration error.
#
# class IrreversibleMigrationExample < ActiveRecord::Migration
# class IrreversibleMigrationExample < ActiveRecord::Migration[0.0]
# def change
# create_table :distributors do |t|
# t.string :zipcode
@ -31,7 +31,7 @@ module ActiveRecord
#
# 1. Define <tt>#up</tt> and <tt>#down</tt> methods instead of <tt>#change</tt>:
#
# class ReversibleMigrationExample < ActiveRecord::Migration
# class ReversibleMigrationExample < ActiveRecord::Migration[0.0]
# def up
# create_table :distributors do |t|
# t.string :zipcode
@ -56,7 +56,7 @@ module ActiveRecord
#
# 2. Use the #reversible method in <tt>#change</tt> method:
#
# class ReversibleMigrationExample < ActiveRecord::Migration
# class ReversibleMigrationExample < ActiveRecord::Migration[0.0]
# def change
# create_table :distributors do |t|
# t.string :zipcode
@ -155,7 +155,7 @@ module ActiveRecord
#
# Example of a simple migration:
#
# class AddSsl < ActiveRecord::Migration
# class AddSsl < ActiveRecord::Migration[0.0]
# def up
# add_column :accounts, :ssl_enabled, :boolean, default: true
# end
@ -175,7 +175,7 @@ module ActiveRecord
#
# Example of a more complex migration that also needs to initialize data:
#
# class AddSystemSettings < ActiveRecord::Migration
# class AddSystemSettings < ActiveRecord::Migration[0.0]
# def up
# create_table :system_settings do |t|
# t.string :name
@ -301,7 +301,7 @@ module ActiveRecord
# rails generate migration add_fieldname_to_tablename fieldname:string
#
# This will generate the file <tt>timestamp_add_fieldname_to_tablename.rb</tt>, which will look like this:
# class AddFieldnameToTablename < ActiveRecord::Migration
# class AddFieldnameToTablename < ActiveRecord::Migration[0.0]
# def change
# add_column :tablenames, :fieldname, :string
# end
@ -332,7 +332,7 @@ module ActiveRecord
#
# Not all migrations change the schema. Some just fix the data:
#
# class RemoveEmptyTags < ActiveRecord::Migration
# class RemoveEmptyTags < ActiveRecord::Migration[0.0]
# def up
# Tag.all.each { |tag| tag.destroy if tag.pages.empty? }
# end
@ -345,7 +345,7 @@ module ActiveRecord
#
# Others remove columns when they migrate up instead of down:
#
# class RemoveUnnecessaryItemAttributes < ActiveRecord::Migration
# class RemoveUnnecessaryItemAttributes < ActiveRecord::Migration[0.0]
# def up
# remove_column :items, :incomplete_items_count
# remove_column :items, :completed_items_count
@ -359,7 +359,7 @@ module ActiveRecord
#
# And sometimes you need to do something in SQL not abstracted directly by migrations:
#
# class MakeJoinUnique < ActiveRecord::Migration
# class MakeJoinUnique < ActiveRecord::Migration[0.0]
# def up
# execute "ALTER TABLE `pages_linked_pages` ADD UNIQUE `page_id_linked_page_id` (`page_id`,`linked_page_id`)"
# end
@ -376,7 +376,7 @@ module ActiveRecord
# <tt>Base#reset_column_information</tt> in order to ensure that the model has the
# latest column data from after the new column was added. Example:
#
# class AddPeopleSalary < ActiveRecord::Migration
# class AddPeopleSalary < ActiveRecord::Migration[0.0]
# def up
# add_column :people, :salary, :integer
# Person.reset_column_information
@ -434,7 +434,7 @@ module ActiveRecord
# To define a reversible migration, define the +change+ method in your
# migration like this:
#
# class TenderloveMigration < ActiveRecord::Migration
# class TenderloveMigration < ActiveRecord::Migration[0.0]
# def change
# create_table(:horses) do |t|
# t.column :content, :text
@ -464,7 +464,7 @@ module ActiveRecord
# can't execute inside a transaction though, and for these situations
# you can turn the automatic transactions off.
#
# class ChangeEnum < ActiveRecord::Migration
# class ChangeEnum < ActiveRecord::Migration[0.0]
# disable_ddl_transaction!
#
# def up
@ -601,7 +601,7 @@ module ActiveRecord
# and create the table 'apples' on the way up, and the reverse
# on the way down.
#
# class FixTLMigration < ActiveRecord::Migration
# class FixTLMigration < ActiveRecord::Migration[0.0]
# def change
# revert do
# create_table(:horses) do |t|
@ -620,7 +620,7 @@ module ActiveRecord
#
# require_relative '20121212123456_tenderlove_migration'
#
# class FixupTLMigration < ActiveRecord::Migration
# class FixupTLMigration < ActiveRecord::Migration[0.0]
# def change
# revert TenderloveMigration
#
@ -673,7 +673,7 @@ module ActiveRecord
# when the three columns 'first_name', 'last_name' and 'full_name' exist,
# even when migrating down:
#
# class SplitNameMigration < ActiveRecord::Migration
# class SplitNameMigration < ActiveRecord::Migration[0.0]
# def change
# add_column :users, :first_name, :string
# add_column :users, :last_name, :string

View file

@ -275,7 +275,7 @@ module ActiveRecord
# when just after creating a table you want to populate it with some default
# values, eg:
#
# class CreateJobLevels < ActiveRecord::Migration
# class CreateJobLevels < ActiveRecord::Migration[0.0]
# def up
# create_table :job_levels do |t|
# t.integer :id

View file

@ -350,7 +350,7 @@ database that Active Record supports using `rake`. Here's a migration that
creates a table:
```ruby
class CreatePublications < ActiveRecord::Migration
class CreatePublications < ActiveRecord::Migration[0.0]
def change
create_table :publications do |t|
t.string :title

View file

@ -35,7 +35,7 @@ history to the latest version. Active Record will also update your
Here's an example of a migration:
```ruby
class CreateProducts < ActiveRecord::Migration
class CreateProducts < ActiveRecord::Migration[0.0]
def change
create_table :products do |t|
t.string :name
@ -72,7 +72,7 @@ If you wish for a migration to do something that Active Record doesn't know how
to reverse, you can use `reversible`:
```ruby
class ChangeProductsPrice < ActiveRecord::Migration
class ChangeProductsPrice < ActiveRecord::Migration[0.0]
def change
reversible do |dir|
change_table :products do |t|
@ -87,7 +87,7 @@ end
Alternatively, you can use `up` and `down` instead of `change`:
```ruby
class ChangeProductsPrice < ActiveRecord::Migration
class ChangeProductsPrice < ActiveRecord::Migration[0.0]
def up
change_table :products do |t|
t.change :price, :string
@ -129,7 +129,7 @@ $ bin/rails generate migration AddPartNumberToProducts
This will create an empty but appropriately named migration:
```ruby
class AddPartNumberToProducts < ActiveRecord::Migration
class AddPartNumberToProducts < ActiveRecord::Migration[0.0]
def change
end
end
@ -146,7 +146,7 @@ $ bin/rails generate migration AddPartNumberToProducts part_number:string
will generate
```ruby
class AddPartNumberToProducts < ActiveRecord::Migration
class AddPartNumberToProducts < ActiveRecord::Migration[0.0]
def change
add_column :products, :part_number, :string
end
@ -162,7 +162,7 @@ $ bin/rails generate migration AddPartNumberToProducts part_number:string:index
will generate
```ruby
class AddPartNumberToProducts < ActiveRecord::Migration
class AddPartNumberToProducts < ActiveRecord::Migration[0.0]
def change
add_column :products, :part_number, :string
add_index :products, :part_number
@ -180,7 +180,7 @@ $ bin/rails generate migration RemovePartNumberFromProducts part_number:string
generates
```ruby
class RemovePartNumberFromProducts < ActiveRecord::Migration
class RemovePartNumberFromProducts < ActiveRecord::Migration[0.0]
def change
remove_column :products, :part_number, :string
end
@ -196,7 +196,7 @@ $ bin/rails generate migration AddDetailsToProducts part_number:string price:dec
generates
```ruby
class AddDetailsToProducts < ActiveRecord::Migration
class AddDetailsToProducts < ActiveRecord::Migration[0.0]
def change
add_column :products, :part_number, :string
add_column :products, :price, :decimal
@ -215,7 +215,7 @@ $ bin/rails generate migration CreateProducts name:string part_number:string
generates
```ruby
class CreateProducts < ActiveRecord::Migration
class CreateProducts < ActiveRecord::Migration[0.0]
def change
create_table :products do |t|
t.string :name
@ -239,7 +239,7 @@ $ bin/rails generate migration AddUserRefToProducts user:references
generates
```ruby
class AddUserRefToProducts < ActiveRecord::Migration
class AddUserRefToProducts < ActiveRecord::Migration[0.0]
def change
add_reference :products, :user, index: true, foreign_key: true
end
@ -257,7 +257,7 @@ $ bin/rails g migration CreateJoinTableCustomerProduct customer product
will produce the following migration:
```ruby
class CreateJoinTableCustomerProduct < ActiveRecord::Migration
class CreateJoinTableCustomerProduct < ActiveRecord::Migration[0.0]
def change
create_join_table :customers, :products do |t|
# t.index [:customer_id, :product_id]
@ -281,7 +281,7 @@ $ bin/rails generate model Product name:string description:text
will create a migration that looks like this
```ruby
class CreateProducts < ActiveRecord::Migration
class CreateProducts < ActiveRecord::Migration[0.0]
def change
create_table :products do |t|
t.string :name
@ -309,7 +309,7 @@ $ bin/rails generate migration AddDetailsToProducts 'price:decimal{5,2}' supplie
will produce a migration that looks like this
```ruby
class AddDetailsToProducts < ActiveRecord::Migration
class AddDetailsToProducts < ActiveRecord::Migration[0.0]
def change
add_column :products, :price, :decimal, precision: 5, scale: 2
add_reference :products, :supplier, polymorphic: true, index: true
@ -563,7 +563,7 @@ to reverse. You can use `reversible` to specify what to do when running a
migration and what else to do when reverting it. For example:
```ruby
class ExampleMigration < ActiveRecord::Migration
class ExampleMigration < ActiveRecord::Migration[0.0]
def change
create_table :distributors do |t|
t.string :zipcode
@ -616,7 +616,7 @@ is wise to perform the transformations in precisely the reverse order they were
made in the `up` method. The example in the `reversible` section is equivalent to:
```ruby
class ExampleMigration < ActiveRecord::Migration
class ExampleMigration < ActiveRecord::Migration[0.0]
def up
create_table :distributors do |t|
t.string :zipcode
@ -659,7 +659,7 @@ You can use Active Record's ability to rollback migrations using the `revert` me
```ruby
require_relative '20121212123456_example_migration'
class FixupExampleMigration < ActiveRecord::Migration
class FixupExampleMigration < ActiveRecord::Migration[0.0]
def change
revert ExampleMigration
@ -677,7 +677,7 @@ is later decided it would be best to use Active Record validations,
in place of the `CHECK` constraint, to verify the zipcode.
```ruby
class DontUseConstraintForZipcodeValidationMigration < ActiveRecord::Migration
class DontUseConstraintForZipcodeValidationMigration < ActiveRecord::Migration[0.0]
def change
revert do
# copy-pasted code from ExampleMigration
@ -841,7 +841,7 @@ Several methods are provided in migrations that allow you to control all this:
For example, this migration:
```ruby
class CreateProducts < ActiveRecord::Migration
class CreateProducts < ActiveRecord::Migration[0.0]
def change
suppress_messages do
create_table :products do |t|
@ -1015,7 +1015,7 @@ to add or modify data. This is useful in an existing database that can't be dest
and recreated, such as a production database.
```ruby
class AddInitialProducts < ActiveRecord::Migration
class AddInitialProducts < ActiveRecord::Migration[0.0]
def up
5.times do |i|
Product.create(name: "Product ##{i}", description: "A product.")

View file

@ -101,7 +101,7 @@ NOTE: `belongs_to` associations _must_ use the singular term. If you used the pl
The corresponding migration might look like this:
```ruby
class CreateOrders < ActiveRecord::Migration
class CreateOrders < ActiveRecord::Migration[0.0]
def change
create_table :customers do |t|
t.string :name
@ -132,7 +132,7 @@ end
The corresponding migration might look like this:
```ruby
class CreateSuppliers < ActiveRecord::Migration
class CreateSuppliers < ActiveRecord::Migration[0.0]
def change
create_table :suppliers do |t|
t.string :name
@ -176,7 +176,7 @@ NOTE: The name of the other model is pluralized when declaring a `has_many` asso
The corresponding migration might look like this:
```ruby
class CreateCustomers < ActiveRecord::Migration
class CreateCustomers < ActiveRecord::Migration[0.0]
def change
create_table :customers do |t|
t.string :name
@ -218,7 +218,7 @@ end
The corresponding migration might look like this:
```ruby
class CreateAppointments < ActiveRecord::Migration
class CreateAppointments < ActiveRecord::Migration[0.0]
def change
create_table :physicians do |t|
t.string :name
@ -304,7 +304,7 @@ end
The corresponding migration might look like this:
```ruby
class CreateAccountHistories < ActiveRecord::Migration
class CreateAccountHistories < ActiveRecord::Migration[0.0]
def change
create_table :suppliers do |t|
t.string :name
@ -345,7 +345,7 @@ end
The corresponding migration might look like this:
```ruby
class CreateAssembliesAndParts < ActiveRecord::Migration
class CreateAssembliesAndParts < ActiveRecord::Migration[0.0]
def change
create_table :assemblies do |t|
t.string :name
@ -384,7 +384,7 @@ end
The corresponding migration might look like this:
```ruby
class CreateSuppliers < ActiveRecord::Migration
class CreateSuppliers < ActiveRecord::Migration[0.0]
def change
create_table :suppliers do |t|
t.string :name
@ -466,7 +466,7 @@ Similarly, you can retrieve `@product.pictures`.
If you have an instance of the `Picture` model, you can get to its parent via `@picture.imageable`. To make this work, you need to declare both a foreign key column and a type column in the model that declares the polymorphic interface:
```ruby
class CreatePictures < ActiveRecord::Migration
class CreatePictures < ActiveRecord::Migration[0.0]
def change
create_table :pictures do |t|
t.string :name
@ -483,7 +483,7 @@ end
This migration can be simplified by using the `t.references` form:
```ruby
class CreatePictures < ActiveRecord::Migration
class CreatePictures < ActiveRecord::Migration[0.0]
def change
create_table :pictures do |t|
t.string :name
@ -514,7 +514,7 @@ With this setup, you can retrieve `@employee.subordinates` and `@employee.manage
In your migrations/schema, you will add a references column to the model itself.
```ruby
class CreateEmployees < ActiveRecord::Migration
class CreateEmployees < ActiveRecord::Migration[0.0]
def change
create_table :employees do |t|
t.references :manager, index: true
@ -575,7 +575,7 @@ end
This declaration needs to be backed up by the proper foreign key declaration on the orders table:
```ruby
class CreateOrders < ActiveRecord::Migration
class CreateOrders < ActiveRecord::Migration[0.0]
def change
create_table :orders do |t|
t.datetime :order_date
@ -611,7 +611,7 @@ end
These need to be backed up by a migration to create the `assemblies_parts` table. This table should be created without a primary key:
```ruby
class CreateAssembliesPartsJoinTable < ActiveRecord::Migration
class CreateAssembliesPartsJoinTable < ActiveRecord::Migration[0.0]
def change
create_table :assemblies_parts, id: false do |t|
t.integer :assembly_id
@ -629,7 +629,7 @@ We pass `id: false` to `create_table` because that table does not represent a mo
You can also use the method `create_join_table`
```ruby
class CreateAssembliesPartsJoinTable < ActiveRecord::Migration
class CreateAssembliesPartsJoinTable < ActiveRecord::Migration[0.0]
def change
create_join_table :assemblies, :parts do |t|
t.index :assembly_id

View file

@ -679,7 +679,7 @@ If you look in the `db/migrate/YYYYMMDDHHMMSS_create_articles.rb` file
(remember, yours will have a slightly different name), here's what you'll find:
```ruby
class CreateArticles < ActiveRecord::Migration
class CreateArticles < ActiveRecord::Migration[0.0]
def change
create_table :articles do |t|
t.string :title
@ -1542,7 +1542,7 @@ In addition to the model, Rails has also made a migration to create the
corresponding database table:
```ruby
class CreateComments < ActiveRecord::Migration
class CreateComments < ActiveRecord::Migration[0.0]
def change
create_table :comments do |t|
t.string :commenter