I've got a problem trying to rollback one of my migration. It seems as if Rails is generating a temporary table for the migration, with temporary indices. My actual index on this table is less than 64 characters, but whenever Rails tries to create a temporary index for it, it turns into a name longer than 64 characters, and throws an error.
Here's my simple migration:
class AddColumnNameToPrices < ActiveRecord::Migration
def self.up
add_column :prices, :column_name, :decimal
end
def self.down
remove_column :prices, :column_name
end
end
Here's the error I'm getting:
== AddColumnNameToPrices: reverting ============================================
-- remove_column(:prices, :column_name)
rake aborted!
An error has occurred, this and all later migrations canceled:
Index name 'temp_index_altered_prices_on_column_and_other_column_and_third_column' on table 'altered_prices' is too long; the limit is 64 characters
I've changed the column names, but the example is still there. I can just make my change in a second migration, but that still means I can't rollback migrations on this table. I can rename the index in a new migration, but that still locks me out of this single migration.
Does anyone have ideas on how to get around this problem?
It looks like your database schema actually has index called prices_on_column_and_other_column_and_third_column. You have probably defined the index in your previous play with migrations. But than just removed index definition from migrations.
If it is true you have 2 options:
The simplier one (works if you code is not in production). You can
recreate database from scratch using migrations (not from
db/schema.rb) by calling rake db:drop db:create db:migrate. Make sure that you do not create this index with long name in other migration files. If you do, add :name => 'short_index_name' options to add_index call to make rails generate shorter name for the index.
If you experience this problem on a production database it is a bit more complicated. You might need to manually drop the index from the database console.
Had this problem today and fixed it by changing the migration to include the dropping and adding of the index causing the long name issue. This way the alteration is not tracked while I am altering the column type (that is where the really long name is caused)
I added the following:
class FixBadColumnTypeInNotifications < ActiveRecord::Migration
def change
# replace string ID with integer so it is Postgres friendly
remove_index :notifications, ["notifiable_id","notifiable_type"]
change_column :notifications, :notifiable_id, :integer
# shortened index name
add_index "notifications", ["notifiable_id","notifiable_type"], :name => "notifs_on_poly_id_and_type"
end
end
Related
I added two migration which in the first one I add a column to a model, and in the second one, I execute a function that stores a value into the column recently added of some rows.
The problem is that when I run rake db:migrate the second migration throws an error because the first migration was loaded but the database hasn't changed yet, so one approach is to run the command twice (it works).
First Migration :
class AddRegisteredReportToSpecialOfferUse < ActiveRecord::Migration
def up
add_column :special_offer_uses, :registered_report, :boolean, default: false
end
def down
remove_column :special_offer_uses, :registered_report
end
end
Second Migration :
class CreateReportsFromMigrations < ActiveRecord::Migration
def change
OneClass.perform
end
end
the OneClass.perform is a method that makes an update of the attribute added previously
def perform
´´´
special_offer_uses.update_attribute(:registered_report, true)
´´´
end
The error thrown :
StandardError: An error has occurred, all later migrations canceled:
undefined method `registered_report=
Note that the method undefined is the name of the attribute added previously.
I wonder if there is a way to avoid running the command twice without throwing any error.
UPDATE:
I found a solution using reset_column_information method that causes the columns to be reloaded on the next request.
Resets all the cached information about columns, which will cause them to be reloaded on the next request.
The most common usage pattern for this method is probably in a migration, when just after creating a table you want to populate it with some default values
Further information : link
Why not do it all in one migration?
class AddRegisteredReportToSpecialOfferUse < ActiveRecord::Migration
def up
add_column :special_offer_uses, :registered_report, :boolean, default: false
OneClass.perform
end
def down
remove_column :special_offer_uses, :registered_report
end
end
I need to add some columns to a table in my schema. Can someone tell me the best way to do this?
The following seems incomplete or wrong since the schema.rb file did not update to include the new column and all of the corresponding view files (edit,index,new,show) did not update to include the new column. Not to mention the bloat of all of those migration classes that get generated. Thanks
ruby script/generate migration RecordLabelToAlbums record_label:string
exists db/migrate
create db/migrate/20121130125859_record_label_to_albums.rb
Creates this:
class RecordLabelToAlbums < ActiveRecord::Migration
def self.up
end
def self.down
end
end
I then added this:
class RecordLabelToAlbums < ActiveRecord::Migration
def self.up
add_column :albums, :record_label, :text
end
def self.down
remove_column :albums, :record_label
end
end
The I ran:
rake db:migrate
Got This:
Mysql::Error: Table 'albums' already exists: CREATE TABLE albums (id int(11) DEFAULT NULL auto_increment PRIMARY KEY, created_at datetime, updated_at datetime)
The code you added is correct.
The error suggests that for some reason your system appears to think it has not yet run the original migration that created the albums table. The state of migrations (in Rails 2) is specified in a table in the database called schema_migrations -- if this gets confused then it will try to re-run migrations. I am not sure what might cause it to get confused, but I do recall this happened a couple times back in 2008 when I was using Rails 2.x.
The table is simple -- you can see what's in it from a SQL prompt -- just the names of migrations it thinks it has run, I think.
If you don't mind losing some data, you can try rake db:rollback or even rake db:reset to get back to the beginning. rake db:rollback STEP=2 will rollback the last 2 migrations.
If you need the data, correct the contents of the table by adding one or more new records referencing the migrations in app/db/migrations that may have been missed. The order is important, I think (the format changed a little in Rails 3, I don't recall how).
Any time you want to add or change the database schema, use rails to generate a migration, and then run rake db:migrate once it's ready to go.
And just asking: is there any way you can move to Rails 3. It's been out for years now, and Rails 4 is coming soon. You'll find yourself in a backwater of incompatibilities, deprecations, security and performance issues and so on if you don't take the hit and upgrade.
so my app was working fine. I created a new model and some associaitons, rendering all the old seed data in my heroku app useless. so I tried to reset it and populate it again. but I can't even migrate my db to heroku with the heroku rake db:migrate command. I'm using SQLite, but it seems my error is related to Postgres. I don't know what that means, if anything
Here is the error:
rake aborted!
An error has occurred, this and all later migrations canceled:
PGError: ERROR: column "to" cannot be cast to type "pg_catalog.int4"
: ALTER TABLE "emails" ALTER COLUMN "to" TYPE integer
Tasks: TOP => db:migrate
My migration:
class ChangeDataTypeForEmailUsers < ActiveRecord::Migration
def self.up
change_column :emails, :to, :integer
change_column :emails, :from, :integer
end
def self.down
change_column :to, :string
change_column :from, :string
end
end
What is the problem? My deployed app was working fine. I added a new model and figured I should reset the deployed database. So I ran heroku pg:reset then pushed my code to heroku. then tried to migrate the db, but it doesn't work! What have I done? I have been trying to figure this out for the last 4 hours. I can't think straight anymore. Any help would be greatly appreciated
Further to Hishalv's answer. If you can't use "change_column" then you can go the roundabout way:
def self.up
rename_column :emails, :to, :old_to
add_column :emails, :to, :integer
Email.reset_column_information
Email.all.each {|e| e.update_attribute(:to, e.old_to.to_i) }
remove_column :emails, :old_to
end
It's roundabout, and the Email.all.each might be slow - but it'll work and correctly cast for you.
If you're only going to use it on prod, then you might be able to replace the ruby-updates with a SQL UPDATE command that does the same thing in-database using a POSTGRES-specific cast method.
As per heroku docs here
Cause: PostgreSQL doesn’t know how to cast all the rows in that table to the specified type. Most likely it means you have an integer or a string in that column.
Solution: Inspect your records and make sure they can be converted to the new type. Sometimes it’s easier to just avoid using change_column, renaming/creating a new column instead.
I also was in this position before and i did not find a solution so i had to create a new column, postgresql seems to be sensitive when i comes to this issues. Hope it helps
In Rails 3,
I created a table with a migration, then added a column with a migration which creates a has_many, belongs_to relationship....
I then ran rake db:migrate
I'd like to now add an Index because I forgot to add it before I can migrate. can I add that to one of the existing migration files (the create table one) or do I need to create a new migration for adding an index to an existing table?
Thanks
I usually create a new migration if I forget something like that (especially if I have already migrated in production). But if you are still in development, then you can alter your last migration file and use the redo rake command:
rake db:migrate:redo
There is also:
rake db:rollback # Rolls the schema back to the previous version (specify steps w/ STEP=n).
Run this command to view all the different rake tasks:
rake -T db
Here is the section in the Rails Guide that talks about it:
http://guides.rubyonrails.org/migrations.html#rolling-back
If you would like to add your index without losing the data, you must create a new migration to add an index. Assuming your model is called Widget and the foreign model is called Zidget;
rails generate migration AddIndexToWidgets
and inside your new migration file at db/migrate/xxxxxxxxxx_add_index_to_widgets
class AddIndexToWidgets < ActiveRecord::Migration
def self.up
change_table :widgets do |t|
t.index :zidget_id # add ':unique => true' option if necessary
end
end
def self.down
change_table :widgets do |t|
t.remove_index :zidget_id
end
end
end
and then rake db:migrate as usual and voilà, you have your indexed column.
Update: If adding an index is all you're doing, there is a more concise way to write the same thing. There is no difference regarding the results. It's just that the former syntax is meant to DRY your code if you have more than one change for your table.
class AddIndexToWidgets < ActiveRecord::Migration
def self.up
add_index :widgets, :zidget_id # add ':unique => true' option if necessary
end
def self.down
remove_index :widgets, :column => :zidget_id
end
end
An old one of my ruby on rails migrations contains both the actual migration but also an action to modify data:
class AddTypeFlagToGroup < ActiveRecord::Migration
def self.up
add_column :groups, :selection_type, :string
Group.reset_column_information
Group.transaction do
Group.all.each do |group|
group.selection_type = group.calculate_selection_type
group.save
end
end
end
def self.down
remove_column :groups, :selection_type
end
end
In this migration there are the usual add_column and remove_column migration statements. But there are also some model specific method calls.
I wrote this a couple of weeks ago. Since then, I have removed my Group model, which gives an error when I do a full migration with :reset.
rake db:migrate:reset
(in /Users/jesper/src/pet_project)
[...]
== AddTypeFlagToGroup: migrating =============================================
-- add_column(:groups, :selection_type, :string)
-> 0.0012s
rake aborted!
An error has occurred, this and all later migrations canceled:
uninitialized constant AddTypeFlagToGroup::Group
The thing is that in the current revision of my code, Group does not exist. How should I handle this "the rails way"??
I am thinking I could modify the migration by commenting out the Group.xxx stuff, but is this a wise way to go?
There is no value in leaving the group stuff in your migration now that it is gone from your project. I'd just edit the migration, drop everything from the db and migrate from scratch. There isn't even a reason to comment it out (you are using version control right?)
Also, I believe the "rails way" with migrations is spelled "Arrrrgh!"