I'm beginner in Ruby on Rails. I dropped my table. But I have the files in the db/migrate folder. How can I get back my table from those migrate files?
The ideal way to do this, is using
rake db:setup
This will recreate the database and load the schema into the development database. With every migration rails keeps the current state of the database in schema.rb (or structure.sql), and it uses those to efficiently recreate the last state.
If you have pending migrations, you will have to do rake db:migrate, but this will take more time, since it will redo every step as before.
Also note in some cases it is not possible to run the migrations from the start again, and imho that is not the intention of the migrations.
Run rake db:migrate to get it back.
According to this question, you should be able to do the following:
rake db:create #-> creates DB based on the schema file
rake db:migrate #-> populates the db with the various changes in the migrations
If you follow these steps, with nathanvda's advice, you should be able to solve the issue you're seeing!
I have screwed up my migrations/schema/db to the point that I can't seem to figure this out.
Locally, I had a comments table. I needed to restructure this table completely, so I opened up my initial "create comments table" migration and altered it manually. I then altered my schema.rb file to match the migration. I then ran rake db:reset and rebuilt my database, and rake db:migrate to finish it off.
This worked seemingly well on my local dev environment. When I pushed to heroku, however, I ran heroku pg:psql and dropped my comments table. I then ran heroku run rake db:migrate thinking it would rebuild the comments table - It did not. The comments table no longer exists, and I can't figure out how to recreate it. I don't have anything important in my heroku database EXCEPT for the users table, so I can't reset the entire thing.
How can I recreate that table, and make sure it matches the migration file I pushed to heroku?
First off, you shouldn't go back into old migrations and manually change them. Just do a new migration with the changes defined there. Read up on migrations here: http://guides.rubyonrails.org/migrations.html
This is done so you don't run into the problem you are currently having. It's also bad practice and if you were working in a group there would be complete mayhem. It's hard to tell exactly what the differences are between your local machine and heroku and what you've changed. My suggestion would be to roll back both your local machine and heroku and do a new migration with your changes.
I'm assuming you are using git so you can go back to a previous version before the change to the create_comments_table on your local machine. You can do the same in Heroku at
https://dashboard.heroku.com/apps/nameofyourapp/activity
In your dashboard you can click on your app and go to the activity tab. There heroku maintains a record of the changes you've pushed. You can rollback to another previous change by hovering over the version.
Now that you have basically restart your app locally and on heroku, you can define a migration with what you want to change in the comments table.
You also might be interested in the PG Backup add-on. Then you won't be as worried about losing data. https://devcenter.heroku.com/articles/pgbackups
I'm working on deploying my first Rails application right now, and somewhere along the way, I botched a migration. When I try to push my application to the production server and run rake db:migrate, it fails somewhere with an error.
Now, I am way too lazy to work through my migrations individually to find out what went wrong, so I'm trying to avoid doing that. Given that my current development database works just fine, is there a way to "flatten" the current schema into a single, comprehensive migration?
I understand that this is sloppy, and I understand that I likely did a dumb thing to break the migration chain in the first place. (I probably edited the database schema directly somewhere, which I now understand is a no-no.) This is a pretty small project though, and I'm essentially the only developer involved, so I'm comfortable sweeping this issue under the rug if possible.
Is there a way to do that?
Thanks for lending your expertise.
This is what the db/schema.rb file is for. If you've only got structural changes in your migrations you will be able to run rake db:schema:load rather than running rake db:migrate to get the absolute structure for your tables.
If you edited the schema directly you will need to run:
rake db:schema:dump
This will take whatever is in the database and create a schema.rb file. Then you can run rake db:schema:load anytime you want. However it will mean that your migrations are still bad. You could delete all of them and recreate them from the schema.rb file.
Does rake db:migrate only add new migrations, or does it drop all migrations/changes and build everything new?
I think rake is throwing an error because it is trying to access a table attribute in migration 040 that was deleted in migration 042. somehow my DB and rake are out of synch and I want to fix them.
for you experts out there - is it common for rake to get out of synch with migrations? how can I avoid this (no, I do not hand-edit my schema or rake files).
When you use rails migrations, a table called schema_migrations is automatically created, which keeps track of what migrations have been applied, by storing the version number of each migration (this is the number that prefaces the migration name in the file name, ie db/migrate/_20090617111204__migration.rb). When you run rake db:migrate to migrate up, only migrations which have not been run previously (ie. their version is not contained in the table) will be run (for this reason, changing a migration that's already been executed will have no effect when running db:migrate). When migrating down, all versions found in schema_migrations that are greater than the version you are rolling back to will be undone.
Everytime you create a migration using scripts (like script/generate model ...) a new migration is added to the correct directory ready to be synched with the real database.
Actually rake db:migrate just checks which missing migrations still need to be applied to the database without caring about the previouse ones.
Of course if you modify the database using other ways is common to obtain out-of-synch things because as you said you can find yourself applying a migration to something that is changed underneath.
A migration means that you move from the current version to a newer version (as is said in the first answer). Using rake db:migrate you can apply any new changes to your schema. But if you want to rollback to a previous migration you can use rake db:rollback to nullify your new changes if they are incorrectly defined. Caution: by doing so your data will be lost.
I have two machines... a development machine and a production machine. When I first brought my rails app onto the production server, I had no problem. I simply imported schema.rb by running rake db:schema:load RAILS_ENV=production. All was well.
So, then on my development machine, I made some more changes and another migration, and then copy the new application over to the production machine. I then tried to update the database by running rake db:migrate RAILS_ENV=production. I get the following error:
"There is already an object named 'schema_migrations' in the database."
I'm thinking to myself, ya no kidding Rake... you created it! I ran trace on rake and it seems as if rake thinks it's the first time it's ever ran. However, by analyzing my 'schema_migrations' table on my development machine and my production machine you can see that there is a difference of one migration, namely the one that I want to migrate.
I have also tried to explicitly define the version number, but that doesn't work either.
Any ideas on how I can bring my production server up to date?
Update:
Let me start off by saying that I can't just 'drop' the database. It's a production server with a little over 100k records already in it. What happens if a similar problem occurs in the future? Am, I to just drop the table every time a database problem occurs? It might work this time, but it doesn't seem like a practical long term solution to every database problem. I doubt the problem I'm having now is unique to me.
It sounds like the 'schema_info' table and the 'schema_migrations' table are the same. In my setup, I only have 'schema_migrations'. As stated previously, the difference between the 'schema_migrations' table on the production server and the development machine is just one record. That is, the record containing the version number of the change I want to migrate.
From the book I read, 'Simply Rails 2', it states that when first moving to a production server, instead of running rake db:migrate, one should just run rake:db:schema:load.
If it matters, I'm using Rails version 2.1.
This is a guess, I admit: I think that because you first ran db:schema:load instead of db:migrate in your production environment, you got the structure of your db, but not the data that migrate populates into your schema_info table. So now, when you run migrate in the production environment, there is no data in schema_info which is why migrate believes that it hasn't run yet (because it hasn't).
That said... you say that you have looked in the "schema_migrations" table, and that there is a difference of one version from dev to production... I haven't heard of that table, although I'm a few months behind on my rails version. Maybe you could try creating a "schema_info" table in the production environment, with a single "version" column, and add a row with the version that you believe your production environment to be on.
If you get "There is already an object named 'schema_migrations' in the database." error message then I suspect that you are using MS SQLServer as your database? (As this seems like MS SQL Server error message)
If yes then which ActiveRecord database adapter you are using? (What is your database.yml file, what gems have you installed to access MS SQL Server database?)
Currently it seems that Rails does not find schema_migrations table in production schema and therefore tries to create it and this creation fails with database error message. Probably the reason is upper/lower case characters in schema_migrations table name - as far as I understand MS SQL Server identifiers are case sensitive.
Depending on the system used in production, I have seen instances where the below does not work:
rake db:migrate RAILS_ENV=production
But where this one does work:
RAILS_ENV=production rake db:migrate
Quirky, I know, but it's worth trying it to see if it makes a difference.
Regarding your update:
I don't understand what the difference is between your production schema_migrations and the dev version. Is there a record in both tables (there should be just 1 column, "version", right) or is there a single record in the dev DB and zero records in production? If there are zero records in the production table, then do this:
ActiveRecord::Base.connection.execute("INSERT schema_migrations (version) VALUES(#{my version number that production is supposedly on})")
Alternatively, you could try dropping the schema_migrations table totally on production:
ActiveRecord::Base.connection.execute("DROP TABLE schema_migrations")
Then, re-running rake db:migrate RAILS_ENV=production. That will run migrations from starting from version 1 though, which is probably not what you're after.
Alternatively alternatively, you could start an IRB session in your production environment, do either a "require" or "load" (I can never remember which, or if it matters) of the migration file that you want to load, and then call MyMigrationClass.up. You would need to manually set the version number in the schema_migrations table after that, as you would still have the problem going forward, but as a quick-fix type of hack, that would work.
I would just drop the DB, add it again and run rake rb:migrate. Brad is correct that when you ran the schema load, it didn't put any records in the schema_migrations table.
This is more complicated of course if there is data you can't lose on the production server. You could get the rake backup tasks (not sure if that is part of core or not) and then run rake db:backup:write on your production database, and then after you get the migrations up to date on production, run rake db:backup:read.
schema_info is from an old version of Rails. schema_migrations is the new kid on the block. You should be able to remove the schema_info table as it'll no longer be used. You'll probably want to search for any issues associated with this name change.
rake db:schema:load will load the database structure from schema.rb. This file is the current representation of the database structure. It's used when you have an empty schema (database) that needs all the tables and indexes creating. It saves you having to run all the migrations. If you have an existing production database with data in, you don't want to run it. As others have said that would be bad!
I know this post was some time ago, but I stumbled across it and it hasn't really been answered. As it comes up on google, here goes.
When you did a rake db:schema:dump (or when this was done for you by the build scripts) it will have put the definition of the migrations table into the schema.rb. At the end of the script, the process will try to create the table again, however it obviously exists already. Just remove the migrations table from the schema.rb before running rake:schema:load and there will be no error message.
You will need to set the version number in the migrations table to subsequently run migrations. So it is important to know what version your schema.rb relates too, or delete all the old migrations (they're safely in your SCM right?)
rake db:migrate RAILS_ENV=production
Use the db:schema:load task just for the first creation, incremental changes should be migrated.