I've dropped my table successfully from the database from the console, using
ActiveRecord::Migration.drop_table(:foo),
But for some reason the table data still shows in the schema file.
I would like a method to do this without having to manually remove the data, (Doesn't give a proper rails feeling to it.)
The schema file located in db/schema.rb was most likely generated the very last time you ran rake db:migrate. This is because rake db:migrate migrates your db through all of the migrations in your db/migrate folder, and then it calls the db:schema:dump task, which generates the schema file based on the current state of the database.
For your situation, after you have run ActiveRecord::Migration.drop_table(:foo) in the rails console, the current state of your database (now, no longer having the table foo) is not in sync with the schema.rb file that was generated when you last migrated.
What you want to do at this point is re-dump the schema based on the current state of the database, and you do this by running rake db:schema:dump. This will take the current state of your database (without the table foo) and generate your db/schema.rb file.
For more information on the schema file and its relationship to migrations, I would recommend looking at the Rails Guide on Active Record Migrations: Schema Dumping and You.
While the answers provided here work properly, I wanted something a bit more 'straightforward', I found it here: link
First enter rails console:
$rails console
Then just type:
ActiveRecord::Migration.drop_table(:foo)
Where :foo is the table name. And done, worked for me!
Related
I feel like this must be a question that has been answered in the past but I could not find anything with Google.
According to the Rails guides:
There is no need (and it is error prone) to deploy a new instance of an app by replaying the entire migration history. It is much simpler and faster to just load into the database a description of the current schema.
However, when you load the database via the schema file there would be no data in the schema_migrations table and therefore any migrations that are added to the project in the future cannot be run without first running the entire migration history.
Am I missing something here? If I create a new instance of the Rails DB from a schema file how can I run any future migrations against it?
It is preferred to set up a new database with a schema load rather than running old migrations, and it should be expected that the schema_migrations table is updated correctly when running a rake db:schema:load. When you run rake db:schema:load the schema_migrations table should be populated based on the value of the version key-pair passed to the ::define method in the db/schema.rb file.
For example:
ActiveRecord::Schema.define(version: 20161208214643) do
end
should update the schema_migrations table up to the migration listed in version. The version value should be populated in the db/schema.rb file automatically after running a rake db:schema:dump or rake db:migrate (which invokes db:schema:dump). This allows for any future migrations to be run normally, as should be expected.
The inserts into the schema_migrations table are handled by the assume_migrated_upto_version method, as seen in the following files:
https://github.com/rails/rails/blob/5-0-stable/activerecord/lib/active_record/schema.rb#L52
https://github.com/rails/rails/blob/5-0-stable/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L1021
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've run all of my migrations and my schema.rb does not include a "create table" line for table that clearly should exist. The table actually shows up in the rails console too, when I access it via its corresponding ActiveRecord class.
Any ideas why this might be happening? And what the consequences of this discrepancy in the schema could have moving forward? The project appears to be working fine.
You can update your schema.rb to mirror the database with this command.
bundle exec rake db:schema:dump
Schema.rb is not used in development or production so it has no effect on a running application. However it is used when setting up the test database. Can read about it more http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you
I'm trying to make a new rails project with an existing database.
I create the projects, configure the database.yml and can successfully do a db:schema:dump
This is all based on what I read on this site
http://blog.joelberghoff.com/2013/02/06/ruby-on-rails-tutorial-creating-a-rails-instance-from-an-existing-mysql-db/
And a few others.
After I do the dump, I copied the schema.rb into db/migrate and renamed to 001_createdatabase.rb as indicated in his tutorial.
Everything seems fine. However I cannot run the site as it tells me i have migrations pending. and the db:migrate:status indicates its that 001_createdatabase.rb that I created.
So based on that:
Was creating that 001_createdatabase migration from the schema.rb the right thing to do?
If it was how do I get rails to understand that it doesn't need to run that one as its already done?
Where does rails check to see if it has pending migrations. Obviously it must check the db/migrate folder and compare it to what?
Thanks
It would seem that in order to get credit for having run the migration, you need to actually run the migration. The migration, 001_createdatabase.rb, represents the migration that will take you from having an empty database -- no tables, no data -- to having your first version of the database. When you run rake db:migrate, rails checks to see if every file in the db/migrate directory has been run by looking for the numerical part of the migration file name in the schema_migrations table.
In your case, you've not run the migration, there is no entry in the schema_migrations table, so rails thinks, rightly, there is a migration to run.
To fix the issue, you can put the record that the migration has been run into schema_migrations or actually run the migration. You may need to create the schema_migrations table, rails will create it as needed.
If you want to run the migration, either drop your database (or create a new one -- you can drop the old one when this works), and point your rails application to the new database. run rake db:create and rake db:migrate. When it completes, you should have a new copy of your database, but one that has been created by the rails migration process. The schema_migrations table should have a record with 1 in the version column.
When I read Rails book, each time they create a new database, always follow a db:migrate.
rails generate scaffold school
rake db:migrate
In console view, I see at first line, Rails create some files, no problem. but in second line, I see that Rails isn't really change anything. I have view some files that Rails nearly create and see no change too.
So, what the purpose of line 2, please tell me.
Thanks :)
The rake migrates the changes into your database. It is which acttually changes the database schema to match your previously generated scaffolded model.
Without it, you wouldn't have a table to write your objects into. Or in case of changed model, the table could differ from your model, leading to error.
When you generate a model (or scaffold one) a migration file is created in your db/migration directory. It is a pure text file, you can create such manually, if you want. This is the tool for the iterative development in rails regarding the database. Each migration adds some change to the system. When you run rake db:migrate your database is updated by the given migrations. This is a handy tool in case of distributed development, when one programmer can check out the code from the repository, and can run the migrations on his own development database.
db:migrate, is the command that tells rails to update the database with new changes. Think of it as this way
when u say rails generate scaffold rails will generate files like a model, controller etc.. and it create a file under db/migrate which has the sql script to update the database.
Ex: if you run rails generate scaffold User name:string, then you will need a table called users in the database with the column 'name', that sql script will generated under db/migrate folder
with db:migrate, command, you are telling rails to migrate new sql scripts to the database, in the above case, it will creates the 'users' table
if you run rake -T, from your rails application root, you could see all the rake tasks
HTH :)