I want to remove column and index in activities table. To do so I've got below migration:
class RemoveUnnecessaryJourneyActivitiesRelations < ActiveRecord::Migration[6.0]
def change
remove_index :activities, :cms_journey_id
remove_column :activities, :cms_journey_id, :bigint
end
end
When I run rake db:migrate it removes this column and index as well but when I want to reset my DB by rake db:drop db:create db:migrate db:seed or bin/rails db:setup I'm getting an error:
rake aborted!
ActiveModel::UnknownAttributeError: unknown attribute 'cms_journey_id' for Activity.
How was the attribute added in the first place? If it was via a migration it looks like that file had been deleted.
You have two options - if you want to get the above migration working, you'll need to insert one before it (with an earlier timestamp) that creates the attribute, and then run this migration to remove it.
Of course, the easier option is to just delete the above migration. Because there is no migration that creates the attribute, you can delete the above migration, run rake db:migrate, have a look at your db.schema.rb file, and you'll see no column called cms_journey_id on the activities table.
Related
I have entrees and snapshots. An entree has_many snapshots. I forgot to add the foreign key to snapshots. So I later added migration:
$ rails generate migration add_snapshot_ref_to_entrees snapshot:references
Migration file looked like this:
class AddSnapshotRefToEntrees < ActiveRecord::Migration[5.0]
def change
add_reference :entrees, :snapshot, foreign_key: true
end
end
This did not do what I want. It added an snapshot_id to entrees, rather than adding an entree_id to snapshots.
So I run the rollback:
bundle exec rake db:rollback
It correctly moves the following from schema.rb:
add_foreign_key "entrees", "snapshots"
And also correctly rolls back the database itself. But the migration file remains in db/migrate. Am I suppose to remove this myself or did not complete its job?
Yes, you need to remove this file manually. Regarding your association, it should be as below:
class AddSnapshotRefToEntrees < ActiveRecord::Migration[5.0]
def change
add_reference :snapshots, :entree, foreign_key: true
end
end
It's not supposed to.
rails destroy migration add_snapshot_ref_to_entrees
In order to rollback a specific migration use:
rake db:migrate:down VERSION=YOUR_MIGRATION_VERSION
For Example:
rake db:migrate:down VERSION=20100905201547
To find the version of all migrations, you can use this command:
rake db:migrate:status
rake db:migrate:down and rollback worked on database label it's not removing file from db/migrate.
You need to remove direct from db/migrate folder.
I tried to create a migration to add roles to my user tables but i accidentally typed AddRolesToUsers instead of AddRoleToUser. So i tried creating a new migration with the correct AddRoleToUsers but when i tried to run rake db:migrate i got an error :
SQLite3::SQLException: duplicate column name: role: ALTER TABLE "users" ADD "role" integer/Users/miguel/.rvm/gems/ruby-2.2.1/gems/sqlite3-1.3.11/lib/sqlite3/database.rb:91:in `initialize'
I tried rake db:migrate:down VERSION= do delete the one I had to type on but i keep getting the same error . PS: i deleted the migration file manually after running rake db:migrate:down VERSION=
rails g migration AddRoleToUsers role:integer
migration file :
class AddRoleToUsers < ActiveRecord::Migration
def change
add_column :users, :role, :integer
end
end
When you ran the first migration, the role column was added to the Users table. The error on the second migration tells you that much.
To clear the migration pending error, you need to comment out the add_column statement in the new migration.
i.e,
class AddRoleToUsers < ActiveRecord::Migration
def change
# add_column :users, :role, :integer
end
end
Then run the migration. This way, the new migration should run successfully.
You can now uncomment it and delete the previous migration, so that when you deploy, only the newer migration is run and the role column is added successfully.
In that case right click and delete both migration files and start again. The error exists because it thinks you want to add two columns both named role to your users table
UPDATE
In that case, if role already exists in your users table, a migration must've been successfully run and there is no need to run another. As long as the role column is there, trying to add another column called role will always give you an error. If you wanted to test that you are still able to add new columns you can always check by creating a test migration AddSomethingToUsers something:string and rake db:migrate to test, then rake db:rollback to undo..but it all seems like it's worked so I probably my wouldn't mess with it too much.
I want to overwrite the existing users table in the database. I have manually deleted the migration file user.rb and model file. After that when I type rails g model User email:string password:string
it creates the above files again but when I run the rake db:migrate command it just gives me the following error:
rake db:migrate
== 20150413203600 CreateUsers: migrating ======================================
-- create_table(:users)
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
SQLite3::SQLException: table "users" already exists: CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "email" varchar(255), "password" varchar(255), "created_at" dateti
me, "updated_at" datetime) /home/action/.gem/ruby/2.1.1/gems/sqlite3-1.3.10/lib/sqlite3/database.rb:91:in `initialize'
If you open up your db/schema.rb file, you will see that you already have a users table. Deleting the migration file doesn't do anything besides not running the migration file if you were to run rake db:migrate on another computer. Run rake db:rollback will delete the last thing that you rake db:migrate, then generate your new user migration along with rake db:migrate.
You should not have deleted the migration file, as rails would have used the migration file under a rake db:rollback command to delete the users table for you.
If you don't mind losing ALL your tables, and since you're using SQLite3, you can look in your db folder for a file called development.sqlite3 and possibly test.sqlite3. Delete those and you no longer have any database tables at all and you can run migrations to re-create them.
If you ONLY want to drop the users table, delete the migrations that you've recently generated to "create user table" and then create a migration rails g migration DropUsersTable then modify it to look like the following
class DropUsersTable < ActiveRecord::Migration
def change
drop_table :users
end
end
Run migration and that will drop your existing users table. Then, you should delete the migration file. As I said, it's not good practice to delete migration files but in this case since you've destroyed the migration that created the original user table, you should destroy the migration that dropped that table.
At this point, you have no migrations that reference users table and you have no users table so you can now generate the migration to create it and this time it should work.
If you change your mind and you want to drop the users table again, remember, DO NOT delete the migration file, just do rake db:rollback then adjust the migration file to create the table as you'd like it and then run rake db:migrate again.
I'm getting an error when trying to run rake db:migrate:
ActiveRecord::StatementInvalid: PG::UndefinedColumn: ERROR: column "plus_ids" of relation "comments" does not exist
I guess I did do some funky stuff when trying to remove the attribute plus_ids from my comment model. I'm not sure what is going on.
If I do a rake db:reset and then fetch the live database it all works locally again, but if I try to do a rake db:migrate it throws an error again.
How can I get rid of plus_ids properly so I can migrate?
Edit 1: Here's the migration files when I added (and removed) the attribute:
class RemovePlusIdsFromComments < ActiveRecord::Migration
def change
remove_column :comments, :plus_ids, :integer
end
end
And then
class AddPlusIdsToComments < ActiveRecord::Migration
def change
add_column :comments, :plus_ids, :integer
end
end
They're in the wrong order in the migration list, not sure why.
Edit 2: I think there is something wrong with the Up/Down, if I run rake db:migrate:status I get this:
down 20150305203336 Remove plus ids from comments
down 20150305204404 Add plus ids to comments
Any way around this?
The answer was to run
rake db:migrate:up VERSION=20150305204404
On both live and local, and then
rake db:migrate
On both again. Now the live and local database is in sync again, and migrating the database throws no errors.
Hi I have a general migration problem:
When I create migrations like this:
class RenameColumn < ActiveRecord::Migration
def change
rename_column :users, :hotel_stars, :rating_stars
rename_column :users, :restaurant_stars, :price_stars
end
end
and change the code in the Model-,View- and Controller file accordingly(I dont create new Model etc.):
ie.
Model: attr_accessible :rating_stars, :price_stars
(instead of :hotel_stars, :restaurant_stars )
Controller: #rating = current_user.rating_stars
When I now run the migration (rake db:migrate) -> it works!
But after a rake db:drop, rake db:create, rake db:migrate it doesn't anymore!
What is wrong with this migration? How can you create migrations that are working WITH and WITHOUT resetting the database?
Thanks!!
I think your issue is that rake db:create does not rebuild your database from schema.rb. For that you need to do rake db:setup instead of rake db:create. In any case I would try rake db:reset instead of drop/create as I believe that will accomplish what you want to do in one step.
Type rake -T for a list of available tasks and what they do.
Also see here for more information on rails migrations:
http://guides.rubyonrails.org/migrations.html
Did you ever manually alter the state of your database and/or modify a migration after it was run? If so, you messed up the state of migrations.
You "could" alleviate this by adding a migration that gets your database where your new migration expects it to be, or you could fix the migration that was altered before.
Depending on how many other developers you have, I would go for the latter in this case.