I have created a table called "property" and I did not migrate it yet. I then wanted to delete the table, so when I did rake db:rollback as below. My previously created table, which I did not want to delete at all, is now reverted. How should I revive my model "comment" and instead delete the last model "property" only.
Some comments say do "redo" or "run migrate" but if I do a rake db:migrate, I feel like it will delete the comment model permanently. Am I wrong? What is right solution to bring back my comment model?
:~/workspace (revoke) $ rails g model property title address note price$ priceW
Running via Spring preloader in process 3066
invoke active_record
create db/migrate/20160517222114_create_properties.rb
create app/models/property.rb
invoke test_unit
create test/models/property_test.rb
create test/fixtures/properties.yml
:~/workspace (revoke) $ bundle exec rake db:rollback
== 20160506122941 CreateComments: reverting ===================================
-- drop_table(:comments)
-> 0.0011s
== 20160506122941 CreateComments: reverted (0.0096s) ==========================
Once you've done the rake db:rollback, you've made a change to the database. In this case, it dropped your comments table, as you can see in the output: drop_table(:comments). The data is gone, already. We've all been there at least once.
Running rake db:migrate will restore the comments table structure, but not the data in it. In this situation, if you want to get to the point that your new table property isn't migrated, you can run rake db:migrate to run all new migrations, and then rake db:rollback once to rollback the migration for property.
Related
I have a problem during migrating 3 models (Game,Page,Section), which is I created 3 models and forget to save it, then directly migrate it. After that, I created a new model called User, then save it, and this User model perfectly saved and migrated successfully. After that when checked schema, those 3 models did not have any fields and did not migrated.
So I did the rake db:rollback, it only rollback to User Model, but I want those 3 Models to be rollbacked. I cannot do new migration to put new values.
Q1 : So do I need to delete those 3 models and create new models?
If it is your personal project just to learn, you can drop your database and, modify migration files and then create and migrate it.
rake db:drop
modify migration files
rake db:create
rake db:migrate
But you will lose all you data in database, so it is very bad idea for future. Better learn how you can create another migrations and add columns you need for your tables.
Look here: add_column
Ot you can always rollback few migrations using rake db:rollback STEP=n
I created an integer for a phone number, and then learned that it is better to consider it as a string due to it's size.
I decided then to change directly the migration and apply db:reset instead of adding a new migration since the project is only on my computer at this moment. Db:reset worked but it doesn't seem that my database changed.
It raised a lot of questions :
Is there a command to analyse a database and identify the types of its columns ?
Does db:reset allow to modify a migration, like after rolling back a migration ?
Even though it isn't preferable, what are the conditions to modify directly a migration ?
The db:reset task resets the database by dropping the database and then loading schema.rb - it does not run migrations again. If you dropped the database, then created it and ran db:migrate then you should get the desired outcome
Change the field as string in migration, then run the commands:-
rake db:drop
rake db:create
rake db:migrate
And it will change the field type from integer to string.
New to Rails here. Couple of questions about migrations:
I created a migration that I no longer want. I want to remove it. Is the correct command simply rails destroy migration AddMyColumnToMyModel ?
Let's say I mistype that migration name that I want to destroy... Here's what happens when I attempt to destroy a migration that does not exist.
$ rails destroy migration Blah
invoke active_record
remove migration.rb
It says it's removing migration.rb... Is this a bad thing?
Sure, that's the right command. Just be careful: if you actually ran the unwanted migration by using rake db:migrate to commit the changes to your database, be sure to run this before anything else:
rake db:rollback
What that does is run the down method on your latest migration. It does absolutely the same thing as:
rake db:migrate:down VERSION=20130529014413
Where the version number corresponds to that of your latest migration. It can also take a STEP parameter in case you need to roll back a bunch of migrations instead of only one, like so:
rake db:rollback STEP=3
Of course, if you just generated your unwanted migration and never ran it, there's no need to roll anything back. You can use the command you posted or manually delete the corresponding file to get rid of it.
Source: http://guides.rubyonrails.org/migrations.html#rolling-back
Don't worry, that's not doing anything to your code.
When I ran bundle exec rake db:test:prepare I got the following:
rake aborted!
Multiple migrations have the name CreateMicroposts
To check the status of my migration files, I ran
rake db:migrate:status
And got:
Status Migration ID Migration Name
------- --------------- -----------------
up 20120616205407 Create users
up 20120622103932 Add index to users email
up 20120622114559 Add password digest to users
up 20120628095820 Add remember token to users
up 20120704123654 Add admin to users
down 20120706103254 Create microposts
up 20120707073410 Create microposts
As you can see, I have two migration files with the exact same names and the exact same code in them. It's only their statuses differ, i.e. Up and Down.
What does Up and Down signify?
And which one can I delete, if I have to?
The problem is that you have two different migration files containing the header
class CreateMicroposts< ActiveRecord::Migration
rake db:migrate:status does not check the status of your migration files. It tells you what migrations will be applied if you run rake db:migrate. The up/down labels are pretty much self-explanatory: it tells you whether the migration will be applied via the up method or the down method. The up method is ran when you migrate and the down when you rollback a migration. You can make some further reading about Rails migrations here.
up is the method called when "evolving" (ie migrating to a new schema), while down is the method called when "regressing" (ie migrating to an older schema version, because one of your changes doesn't suit you). db:migrate calls up, db:rollback calls down. In recent versions of rails, there's change that handles both at the same time.
As for the deletion... I don't do activerecord much these days, but I think you're free to do whatever you want with your files. I don't think deleting a duplicate file will do any harm, and if it does.. Well, you use source control, right ? :)
My Environment -> Ruby 1.9.2 and Rails v3.0.5
I noted a strange pattern in rake db:reset. According to rails source code, rake db:reset will => db:drop, db:create and db:migrate. https://github.com/rails/rails/blob/v3.0.5/activerecord/lib/active_record/railties/databases.rake#L159
Setup: One of my migration files have Model.create statements to populate some data (Forgive me, I'm not the one who had put data-filling-code in those migrations :) ..)
Case 1: When I do the steps manually, i mean drop, create, and migrate, one by one - those statements fill data in the table.
Case 2: When I do just rake db:reset, schema is set properly. but the data is not entering the db. Does db:reset skip create/update statements.. I have tried this several times to make sure that I have no faults in the steps I do. I still get this behavior.
what is going wrong here... ?
I think you're reading the wrong line in the source. As I read it:
db:migrate:reset # => [:drop, :create, :migrate]
db:reset # => [:drop, :setup]
So db:reset just create the tables and sets the migrations as if they had been run, without actually running them. db:migrate:reset actually runs each migration.
I had the same problem before but I was running 3.0.3, and it turns out, somehow I manage to mess up the migrations by change the migrations files and not running the migrations(forgot about it or something)...I'll start by checking those files