I'm getting an error:
SQLite3::SQLException: no such column: ideas.list_id:
SELECT "ideas".* FROM "ideas"
WHERE "ideas"."list_id" = 2
But I added
t.integer :list_id
to my db migration file:
class CreateIdeas < ActiveRecord::Migration
def change
create_table :ideas do |t|
t.string :name
t.text :description
t.string :picture
t.timestamps
end
add_foreign_key :ideas, :lists
end
end
which gave me this:
class CreateIdeas < ActiveRecord::Migration
def change
create_table :ideas do |t|
t.string :name
t.text :description
t.string :picture
t.integer :list_id
t.timestamps
end
add_foreign_key :ideas, :lists
end
end
and then I typed
rake db:migrate
Any idea why I would be getting an error saying there's no column? I'm still new to RoRs. Do I have to add a column some other way?
Thanks
As Speransky suggested, you should never modify old migration files. Rather you should create a new migration that adds the desired column. For instance, in this case you would run the following command in your app to create the new migration:
rails generate migration AddListIdColumnToIdeas list_id:integer
And Rails would generate the migration file automatically and the only thing left to do is run rake db:migrate.
If you insist on modifying the old migration file, you can add the column as you did and run the following:
rake db:drop
rake db:create
rake db:migrate
Which will destroy your current database, create a new one and run all the migrations (which will include your new column).
If you want to add a new column to an exist database, you should use rails generate migration. So you can try rails generate migration add_list_id_to_ideas list_id:integer and then use rake db:migrate to commit this change.
You should not add new rows to old migrations. Migration is a step of building database. And number of last executed migration is stored in schema, and it will not be run or redone if you use will use rake db:migrate. If you run the migration with creating the table before, then you should create new migration where you may use add_column method.
migration file name has the datetime encoded in its name so rails run this migration one and do not run it again unless you do a rollback
and here come the magic of migration to build you db with small steps so no need to update a migration after run rake db:migrate , you should make a new migration to do the change you want to your db schema
and remember to
remove the added line form the old migration file as it might raise errors if you decided to rollback this migration
Rails 4.0 easy way to add single or multiple column
https://gist.github.com/pyk/8569812
You can also do this ..
rails g migration add_column_to_users list_id:string
then rake db:migrate
also add :list_id attribute in your user controller ;
for more detail check out http://guides.rubyonrails.org/active_record_migrations.html
If you already have files in your migrate folder, you could just add column you want there(just type the code), delete development.sqlite or whatever represents your db file, and run rake db:migrate.
It will then create a new sqlite file with new column in table, and you can check it in schema.rb
So, basically, everything you did seems good, except you didn't delete your database file.
Doing this seems the easiest for me, all though you will lose all the files in your database. If you're just testing and developing Rails app, this works.
Can anyone comment if there is something wrong with this approach, besides what i wrote?
Edit: I actually found an answer about that here
Editing Existing Rails Migrations is a good idea?
Related
I have the following migrations
Problem is that rake db:migrate is not executing the first migration and no users table is created.
What could be the reason for this?
What could be the reason for this?
Main reason is probably that you've already ran the migration - or perhaps later migrations - and Rails therefore does not think it needs to run it.
A good way to see if this is the case is to open your db/schema.rb file:
You'll see the latest migration your schema is running. If this supersedes the one you're trying to invoke, it will not run.
--
Fixes
You could generate a new migration, and copy the code over:
$ rails g migration AddUsers2
You'd then add the following:
#db/migrate/_____.rb
class AddUsers2 < ActiveRecord::Migration
def change
create_table :users do |t|
t.string :name
t.timestamps
end
end
end
Alternatively, you could wipe your DB and start again. This can be achieved using rake schema:load. THIS WILL WIPE ALL DATA AND START AGAIN
I am working on my first ruby on rails project, and have created a "Users" table for my app using a "rails generate scaffold users" command.
Now I am trying to undo this statement as I wish to try to rewrite the classes involved with that class and table in my database.
I saw that the scaffold statement created a "def change" class in a migration, and when I try to rollback that migration there is no function within the migration. I added a "def down" method with only the "drop_table :users" defined within it.
def down
drop_table :users
end
However, when I run "rake db:rollback", there is no response in the command prompt and the table is unchanged.
I am not quite sure how to undo this migration to rewrite the table schema. Can anyone offer assistance please?
The whole migration looks like the following:
class CreateUsers < ActiveRecord::Migration
def change
create_table :users do |t|
t.string :name
t.string :password_digest
t.string :email
t.timestamps
end
end
def down
drop_table :users
end
end
EDIT:
Fixed this by running db:drop and db:rollback to clear my schema. I think there was an issue with me having the database open in another program. I closed it and that allowed the database to be rolled back.
rails generate scaffold users doesn't change your database, it only generate MVC code. You can simply undo it by destroy scaffold command
rails destroy scaffold users
If you run rake db:migrate command than you can rollback it by rake db:rollback command. At migration file, change method is enough for create or drop operation of tables. No down method is needed, down method is the complement method of up method.
Ok so you've built your model 'rails generate model test (inputs)' you've rake db:migrate checked your schema file all looks good and working and writing to sqlite. But then you realise you need another attribute in the DB. One way is to rake db:rollback, make change in the migrate file, rake db:migrate again and hey presto all looking good. However doing rake db:rollback has lost all my data already stored in the sqlite. So I'm guessing this is not the correct way to do this? What is the best way?
class CreatePosts < ActiveRecord::Migration
def change
create_table :posts do |t|
t.text :title
t.text :requester
t.text :requester_email
t.text :customer
t.text :contact
t.text :customer_email
t.text :customer_phone
t.string :type_of_change
You can generate a new migration with rails g migration <migration_name> (eg. rails g migration add_foo_to_blah) and then inside that new migration, make the changes you need.
eg. you can add new columns, rename columns, etc.
For more information: http://guides.rubyonrails.org/migrations.html#creating-a-standalone-migration
In fact db:rollback is best way. Of course when you do db:rollback it will wipe away your existing data,but you need to do db:migrate to get the data appear again in the tables.
If you don't want to do rake db:rollback,then create another migration file which will do the job for you.
Edit
You need to perform the below command to get that column added in your posts table.
rails g migration AddImplementerToPosts implementer:text
and do rake db:migrate to make sure that column added in your table.
Yes, db:rollback takes back the last migration, so if in last migration you added some columns, db:rollback will remove them (and if you change the migration and run it again, these fields will be added, but data is already lost).
The proper way to add more fields is to generate new migration and add these fields there.
Running through Michael Hartl's well known Rails tutorial, hit this snag.
I have this in a migration file, created by rails generate model etc:
class CreateUsers < ActiveRecord::Migration
def change
create_table :users do |t|
t.string :name
t.string :email
t.timestamps
end
end
end
Later, I added this second migration file:
class AddIndexToUsersEmail < ActiveRecord::Migration
def change
add_index :users, :email, unique: true
end
end
To try and update the database to include the new one, I followed the instructions and ran rake db:migrate, but this gives me an error telling me I'm trying to create a table that already exists, which is to say I'm clearly missing something.
Am I...supposed to delete the first migration? That wouldn't make any sense. What to do?
(These are the only files under db/migrate)
if you realy want to see what migrations have been ran into the database, you can inspect your app database, there is a table called schema_migrations, in there you can see the unique id of each migration as a row for example is your migration is called: 20130402190449_add_flagand_table.rb, you should see the number 20130402190449 as a row of that table, hope i gave you some guidance
What you can do is rollback couple of migration and re-run.
You can rollback migration like this
#rake db:rollback STEP=2
and then run
#rake db:migrate
Hope it should work
My issues was my 2nd to last migration ran and it was trying to rerun that migration again after i added a new migration.
I ended up just commenting out the code inside the one it was trying to rerun, and then ran rake db:migrate then uncommented the migration code.
This way the schema does not break and it fixes whatever bug occurred.
I happened to create a Query model in Rails and recently found out that this is one of the reserved words now..
I renamed the table using a new migration file and renamed all the files that were created (name of new model - Plot)
Question: is it OK to rename the original migration file (20111228212521_create_queries.rb) to 20111228212521_create_plots.rb)
and everything inside the old file:
class CreateQueries < ActiveRecord::Migration
def change
create_table :queries do |t|
t.string :name
t.text :content
t.timestamps
end
end
end
to
class CreatePlots < ActiveRecord::Migration
def change
create_table :plots do |t|
t.string :name
t.text :content
t.timestamps
end
end
end
??
I just don't want too many migration files and also worried that there may be some errors when I switch to production..
You can change the migration file name, but you have to perform a few steps:
rake db:rollback to the point that queries table is rolled back.
Now change the name of migration file, also the contents.
Change the name of any Model that may use the table.
rake db:migrate
The short answer is to just make another migration file.
Migration files are meant to keep track of each and every change to the database. So, you're encouraged to make small one-off changes in a separate file. I can't speak for your situation, but in my situation, when I make a mistake like this, I simply create a new migration file and don't check the old migration file into source control. This way the errant changes are only on my local db and don't get into prod/dev/staging.
Aside from rolling back, and especially useful for when you need to rename a migration from early on in production you can now in Rails 4 create a new migration to rename it.
$rails generate migration RenamesFooBarr
and then in the method of the new migration add
rename_table :old_migration_name, :new_migration name
like this:
class RenamesFooBar < ActiveRecord::Migration
def change
rename_table :old_foo_bar_name, :new_foo_bar_name
end
end
This will effectively take care of all the indexes as well in the up and down since ActiveRecord recognizes the rename_table
source: http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
Simply, do like this
Rollback the migration for that queries. i.e rake db:rollback
Change migration file, class name and the content of it.
Finally, Migrate the database. i.e rake db:migrate