I use rails db:migrate as usual in Rails, but there are some people who are actually using it and do not know what they are actually doing?
Until recently, somehow, I didn’t understand ah migration file is reflected in the database~.
However, while studying deeply, I wondered, “What does each Rails command do after all?”, so I summarized it in this article.
migrate is the act of reflecting the contents of the migration file in the DB
From the conclusion migrate is the act of reflecting the contents of migration file in DB Will be.
However, this alone is weak, so I’m going to dig a little deeper.
About MVC model
First of all, the basic recognition part, but the framework called Ruby on Rails uses a model called MVC.
I will omit the details here,
- Controller that executes an action in response to a request from the server
- Model that interacts with the database (DB)
rails g model
- View responsible for browser display
It consists of three parts.
rails g model
Before understanding migration, let’s first understand the model creation command.
When you execute the rails g model command, it is roughly divided into two types, model file and migration file (strictly speaking, test file etc. are also automatically created).
Each of these files
- migration file -> contents to change DB
- model file → connect DB and Rails application
There is a role such as.
In particular, all the models created here inherit a class called ApplicationRecord.
class User <ApplicationRecord # Include default devise modules.Others available are: # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable end
Furthermore, the parent class of this ApplicationRecord class extends ActiveRecord::Base.
class ApplicationRecord <ActiveRecord::Base self.abstract_class = true end
This ActiveRecord class has the function to translate the SQL syntax required when interacting with the DB.
Therefore, ** you can easily access the DB and manipulate the data without writing SQL syntax **.
It may be unfamiliar to get in from Rails, but usually in order to access the DB and manipulate the data, you have to skip the instructions using another language SQL.
SQL statement example
- -Create table CREATE TABLE USERS ( ID INT NOT NULL PRIMARY KEY, NAME VARCHAR NOT NULL AGE INT NOT NULL ); - -Create data (table.create(value1, value2…) in rails) INSERT INTO USERS VALUES (1,'Ichihara',''); - -Select all data (model.all in rails) SELECT * FROM USERS
However, with Rails, you can use this ActiveRecord to automatically translate it into SQL and operate the DB with **a more intuitive and simple syntax.
Also, in this ActiveRecord::Base class, getters and setters are automatically defined, so you can refer to the instance value without intentionally defining attr_accessor.
So that’s it… It’s certainly convenient, but why did you struggle to understand getters and setters?
When rails db:migrate is executed, DB is changed based on the created migration file. In this case, a new table will be created on the DB for migration when creating the model.
class CreateUsers <ActiveRecord::Migration[5.1] def change create_table :users do |t| t.string :name t.timestamps end end end
The table created by ActiveRecord has the following features.
- The table name is a plural form of model (Post → posts)
- id, created_at is automatically created
By the way, when a migration file is created by rails g migration, the change method is automatically defined, and you can make changes to the already created table.
class PasswordDigestToUsers <ActiveRecord::Migration[5.1] def change add_column :users, :password_digest, :string end end
That is all about migration.
I am not very confident, so I would appreciate it if you could point out the wrong commentary on Lee!