I am still new to rails and I have some questions regarding rails migration.
I am using rails 5, windows 8. I generated a model and wrote some code which creates a table with columns. Then I deleted that table from my development db (MySQL) and tried to execute db:migrate again to see if it would create the table and columns written in the migration file. After executing db:migrate, it didn't show any messages in the terminal and it did not create the table and the columns.
Based from my observation, deleting the version of my migration file from schema_migrations and running db:migrate once again, it worked and created the table and columns.
I would like to ask the pros of rails development on why is this happening and what should I do when I start to develop a large database model.
I would also like some suggestions about great resource materials for learning ruby on rails.
Thanks!
Its because rake db:migrate is running only migrations for the current env that have not run yet. So if you run db:migrate and then manually delete table form DB, your app does not know that.
MIgration Guides
Related
Been able to make migrations (add columns etc) on my local machine with mysql.
But when trying to push these migrations to Heroku, they continue to fail.
The first table in my migration file gets tagged with:
Mysql2::Error: Table 'xxxxx' already exists
locally all my migrations showing as:
up 20171127214206 Add tags to business
but when running heroku run rake db:migrate:status
down 20171127214206 Add tags to business
i don't mind losing all the data at this point as i'm working in a development version on Heroku and will merge later with production
been working on this issue for over a day, so any and all advice appreciated.
according to this and many other sources, it appears you're better to use postgresql adapter with heroku. If you want to do that, you need to edit your database.yml similar to this
I ran a simple rails migration on a large MySql2 db to add a column to a table:
class AddMiddleNameToPerson < ActiveRecord::Migration[5.0]
def change
add_column :person, :middle_name, :string
end
end
I was disconnected from the server running the rails app during the migration. I then reconnected and checked the migration status with bundle exec rake db:migrate:status, which showed it as down:
down 20170424182410 Add middle name to person
I assume it was still running in the background. So I left it for some time, and eventually using the rails console I verified that person.middle_name was accessible on objects. However, db:migrate:status still shows the migration as down, and if I try to run db:migrate again I get an error:
Mysql2::Error: Duplicate column name 'middle_name'
So it seems that the new column is in the database, and accessible through ActiveRecord, but rake db:migrate:status finds the migration as down and rake db:migrate attempts to re-run it, unsuccessfully.
If this is a production database (or other database with important data) then do not rake db:reset as that will drop the database and you'll lose everything; also don't db:migrate:down as that will drop the middle_name column and you'll lose whatever middle names you already have.
First get a backup of the database or at least the table you're working with.
Second, connect to the database with the mysql CLI tool and say describe people;. The information in your question suggests that you will see the middle_name column in there but it doesn't hurt to make sure you're connecting to the right database. If middle_name isn't there then you're almost certainly connecting to the wrong database somewhere, if it is there then you just have a migration issue to clean up.
You say that the database connection was dropped before the migration finished. Migrations work in this sequence:
Run the migration to update the database.
Record the migration's version number in the schema_migrations table.
Regenerate db/schema.rb or db/structure.sql.
If 1 completes but the connection is lost then 2 never happens so the migration will have run but Rails won't know it.
If no other environments need the migration then you can simply delete the migration and rake db:schema:dump or rake db:structure:dump to get a fresh schema.rb or structure.sql. Migrations are just temporary bits of code to get you from A to B so deleting them after they've been run everywhere is fine (and even recommended), all that matters long term is your database's structure (which is in db/schema.rb or db/structure.sql).
If other environments need to run the migration then you can manually patch the schema_migrations table; connect to the database with the mysql CLI tool and say insert into schema_migrations (version) values ('20170424182410');. Rails will now know that the migration was run and future rake db:migrate calls will be happy. Then you'd want to refresh your schema.rb (with rake db:schema:dump) or structure.sql (with rake db:structure:dump).
You probably have a db/schema.rb file for tracking your database's structure (including the version numbers of the migrations that have been run). If you do then you'd use rake db:schema:dump to regenerate it. If you have db/structure.sql then you'd use rake db:structure:dump.
Ubuntu, rails 4.1, capistrano 3.1
I deployed my rails app to server with Capistrano, and during this procedure, db:migration was executed and database has been build up.
However, later I created new migrations, and when I use "cap production deploy", it shows my original db misses some table (db:migration not executed on my new migrations); and when I use "cap production deploy:migrate", then capistrano will run all the migrations (including those that have already been executed before), so it report some table already exist (of course they exist before).
My question is, how can I just execute db:migrate on those newly created migrations ?
Thanks
I think I know the answer:
It's nothing wrong with Capistrano!
During the deploy procedure, it will do things by this sequence:
1. udpate code
2. rake assets:precompile
3. rake db:migrate
Step 2 will somehow load the app, which will execute all initializer code. But here I access new db table, which should be created in #3. So this cause table missing error.
Just wonder why loading app during assets:precompile, what's the use of it?
Can we don't do that?
Using rails 3.2.8 ruby 1.9.3 p362.
There is something seriously amiss with my rails app. After so many db issues with an app, I STARTED FROM SCRATCH - read: rails new < new app name>
And started adding scaffolds and models. All in the past hour or so.
Then I tried to migrate a model called Product and I got the "Mysql2::Error: Table 'products' already exists" message when I ran rake db:migrate
Lo-and-behold my schema.rb file transformed itself into the mess of a file I had on my old app (on a different folder).
How can this happen? And how can I fix it?
Also, how often should I be pushing to git? I pushed once before building 2 new models and I already have a mess in my hands.
Help, please!
Did you clean up the old database for migrations from your older app / create a new database for the new app? Looks like it is the older database which is causing the issues.
You can go to your mysql prompt, and do a drop database database_name; and recreate an empty database using create database database_name.
I have created an app using a badly named database, all alterations to important data in the database have been done in fixtures so that I can just drop the database, recreate it and then rake migrate the database tables and fill them with the initial data from the fixtures.
I would like to change the name of my database now, so I updated the database.yml file to reflect another database name. I created the database in mysql and then tried to run the migration and fixtures.
Running the migration with trace shows that it is running commands to create tables etc. However once I am finished I get errors in my application saying that the tables don't exist in the new database.
I go into mysql and check the database and it is completely empty. I have tried wiping everything and running the migrations a few times but nothing changes. Is there something I am missing?
I don't know what commands you used to do the migration, but to migrate a production database (which I infer from the tag, "production-environment"), you have to do:
RAILS_ENV=production rake db:migrate
If that's not the answer, then please provide the command you used to perform the migration, which database you expected to be affected, and the relevant bits of database.yml.