I'm a beginner at Rails.
How does migration work?
My senior taught me the following things.
"Rails compares the migration file to the schema_migrations table
Automatically find and execute unexecuted migrations"
So I'm going to write
in one of the multiple migration files that are already running.
I did the following.
Before Run
t.string:name
t.string —email
t.string —address
Post Run
t.string:name
t.string —address
I deleted the email line.
Then we ran rakedb:migrate.
My prediction is that the email column will be deleted in schema.rb.
As a result, there was no change.
On the contrary, adding one column gave the same result.
Why is this?
カラム I know it's not a good way to add/remove columns, but I want to know why.
ruby-on-rails database
I think you know that the migration file is below db/migrate.
I think the migration file has 14 digits at the beginning of the file name.This is the date and time when the migration file was created, and this is the version.
Rails uses this version to manage migration and maintains to which version the migration file has been adapted.
The current version is
$rails db:version
You can see it in the
In , with a migration file of a version newer than this current version,
$rails db:migrate
This will adapt the contents of the migration file for the new version.
If the migration file that Shonen was bullied was as follows,
db/migrate/20171114000000_create_users.rb
If the current version is 20171114000000, no matter how many times you run rails db:migrate, changes made to 20171114000000_create_users.rb will not be applied.
In other words, to adapt the 201711140000_create_users.rb, you must rails db:migrate with the current version older than 20171114000000.
To age the version, use the
rails db:rollback
Run the .
Then the version will be one version older than 20171114000000.
In this state, if you edit 201711140000_create_users.rb and rails db:migrate again, any changes you make to 20171114000000_create_users.rb will be adapted to DB.
It's a mistake to...
If you try rails db:rollback in Shonen's environment, you will probably get an error.
This is because rails also check the table and migration file information when rails db:rollback.
For example, try to rollback by erasing the column email:string like this time.
The rails try to delete the table according to the migration file, but the migration file leaves an email column with no information.I think rails will throw up errors because it doesn't make sense.
So,
·Return the migration file to the state you created
·db: Rollback.
·I'll play with the migration file.
·db: Migrate.
is the correct procedure.
Even so, if you mess with a lot of things, you won't know what the original condition was, so it's hard to get it back to the right one.
If so, try doing the following:
rails db:migrate:reset
If you do this, you can put the DB straight and adapt all migration files in order from the old one.Of course, everything in the DB will disappear, so please be careful.
Also, you may not be able to run rails db:migrate:reset.
In that case, I think the error content says bin/rails db:environment:set RAILS_ENV=development, so please do so accordingly.
The schema_migrations table contains the "version" portion of the migration file.Version is typically the value of the timestamp portion of db/mgirate/time stamp_migration name.rb.
If there is a version in the table, it is determined that it has been applied.On the other hand, we do not see the contents of the file or the time of modification, so rewriting the contents does not determine that it has not been executed.
The db:migrate:status task can also be used to determine which migration files will be applied (shown as down)
Another tool that can be applied by rewriting schema definition files is called ridgepole.
© 2024 OneMinuteCode. All rights reserved.