将列类型更改为 Rails 中的较长字符串

在第一次迁移时,我在一个列 content上声明为字符串 Activerecord 根据注释 gem 将其设置为 string (255)。

在我把应用程序推到 heroku 之后,它使用 postgres,如果我在表单内容中输入一个长于255的字符串,就会得到错误

PGError: ERROR: value too long for type character varying(255)

问题是,我需要的内容包含一个字符串,可能是非常长(自由文本,可能是数千个字符)

  1. Pg 会接受哪个变量(字符串不适合这个变量) ?
  2. 如何创建迁移以替换该列的类型

谢谢

60702 次浏览

You should use text with Rails if you want a string with no length limit. A migration like this:

def up
change_column :your_table, :your_column, :text
end
def down
# This might cause trouble if you have strings longer
# than 255 characters.
change_column :your_table, :your_column, :string
end

should sort things out. You might want :null => false or some other options on the end of that too.

When you use a string column without an explicit limit, Rails will add an implicit :limit => 255. But if you use text, you'll get whatever arbitrary length string type the database supports. PostgreSQL allows you to use a varchar column without a length but most databases use a separate type for that and Rails doesn't know about varchar without a length. You have to use text in Rails to get a :limit => 2557 in PostgreSQL. There's no difference in PostgreSQL between a column of type text and one of type varchar (but varchar(n) :limit => 2558 different). Furthermore, if you're deploying on top of PostgreSQL, there's no reason to use :limit => 2550 (AKA varchar) at all, the database treats text and varchar(n) the same internally except for the extra length constraints for varchar(n); you should only use varchar(n) (AKA :limit => 2550) if you have an external constraint (such as a government form that says that field 432 on form 897/B will be 23 characters long) on the column size.

As an aside, if you are using a string column anywhere, you should always specify the :limit as a reminder to yourself that there is a limit and you should have a validation in the model to ensure that the limit is not exceeded. If you exceed the limit, PostgreSQL will complain and raise an exception, MySQL will quietly truncate the string or complain (depending on the server configuration), SQLite will let it pass as-is, and other databases will do something else (probably complain).

Also, you should also be developing, testing, and deploying on top of the same database (which will usually be PostgreSQL at Heroku), you should even use the same versions of the database server. There are other differences between databases (such as the behavior of GROUP BY) that ActiveRecord won't insulate you from. You might be doing this already but I thought I'd mention it anyway.


Update: Newer versions of ActiveRecord do understand varchar without a limit so, with PostgreSQL at least, you can say:

change_column :your_table, :your_column, :string, limit: nil

to change a varchar(n) column to varchar. text and varchar are still the same thing as far as PostgreSQL is concerned but some form builders will treat them differently: varchar gets an <input type="text"> whereas text gets a multi-line <textarea>.

While the accepted answer is excellent, I wanted to add an answer here that hopefully better deals with the original posters question part 2, for non experts like myself.

  1. How do I create a migration to replace the type of that column

generating scaffold migration

You can generate a migration to hold your change by typing in your console (just replace the table for your tables name, and column for you column name)

rails generate migration change_table_column

This will generate skeleton migration inside you Rails application /db/migrate/ folder. This migration is a placeholder for your migration code.

For example I want to create a migration to change the type of a column from string to text, in a table called TodoItems:

class ChangeTodoItemsDescription < ActiveRecord::Migration
def change
# enter code here
change_column :todo_items, :description, :text
end
end

Running your migration

Once you've entered the code to change the column just run:

rake db:migrate

To apply your migration. If you make an error you can always revert the change with:

rake db:rollack

Up and Down methods

The accepted answer references Up and Down methods, instead of the newer Change method. Since rails 3.2 old style Up and Down Methods presented a few advantages over the newer Change method. 'Up and Down' avoid ActiveRecord::IrreversibleMigration exception. Since the release of Rails 4 you can use reversible to avoid this error:

class ChangeProductsPrice < ActiveRecord::Migration
def change
reversible do |dir|
change_table :products do |t|
dir.up   { t.change :price, :string }
dir.down { t.change :price, :integer }
end
end
end
end

Enjoy Rails :)