Rails Tutorial (4th Edition) Personal Notes Describe the part you are interested in and the part you may forget.
You created the Users controller at the end of the previous chapter (5.4). The continuation. From Chapter 6 to Chapter 12, we will create each function of user authentication. Of these, Chapter 6 deals with the user's data model and storage.
Rails already has a mechanism for implementing authentication, but each service requires a lot of custom authentication. This is a reinvention of the wheel, but the Rails tutorial reinvents the wheel because it's easier to implement third-party certification if you know how to do it.
Rails calls the default data structure that treats it as a data model Model (M in MVC).
Rails defaults to ʻActive Record` to interact with this Model.
This is something that does CRUD and construction without being aware of SQL.
Create a User model to persist the database.
Just like when creating the Users controller, $ rails g.
As a reminder
The controller is ** plural ** ʻUsers The model is ** singular ** ʻUser
It is customary to say.
$ rails g model User name:string email:string
Pass the attribute used in DB (column name in DB) and the type with : in between.
Although various files are generated, a file named timestamp_create_model name s.rb is created indb / migrate /.
Information for creating a DB is defined here.
db/migrate/Time stamp_create_users.rb
class CreateUsers < ActiveRecord::Migration[5.0]
def change
create_table :users do |t|
t.string :name
t.string :email
t.timestamps
end
end
end
The id and time stamp are automatically prepared even if you do not specify them.
Looking at the class name part, it seems that it inherits ʻActiveRecord :: Migration [5.0]. (5.0 in Rails tutorial, but 5.1 notation for my environment) timestamps creates two columns for timestamps [ created_at, ʻupdated_at].
Is it like this with mysql?
mysql
CREATE DATABASE User;
USE Users;
CREATE TABLE users(
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(300),
email VARCHAR(300),
created_at TIMESTAMP NOT NULL CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP
);
Every time I write sql, I'm writing that an uncle who doesn't allow uppercase or lowercase letters is likely to occur (I was also in my previous job). To be honest, I think it's okay to use all lowercase letters in this age. ~~ By the way, in my previous job, write the date in varchar () and stop doing crap ~~
Apply migration. According to a friend, I was reminded that it was a command to explode with special care in multi-person development. Let's be careful. The DB side is not version controlled.
$ rails db:migrate
** Exercise ** I did ʻUser.new` in the Rails console and checked what kind of inheritance relationship it has.
ʻUser class <ʻApplicationRecord <ʻActiveRecord :: Base <ʻObject <BaseObject
Will roll back all changes to the DB at the end.
$ rails console --sandbox
Experiment in this.
The user class was created when the model was created (ʻapp / model / ), which is inherited from ʻActiveRecord.
Method used below
valid?: Confirmation of validity (Validity)
save: Save
When saved, a time stamp is stamped on create_at, ʻupdate_at`.
In the return value, the bool value of whether or not it was saved is returned.
create: User.new only creates it in memory, but saves it as soon as it is created.
** Exercise ** User.create user.name ActiceSupport::timeWithZone
In short, it's like specifying a column type in SQL.
For : email, Double or Boolean is not included.
The following 4 points
--Presence --Length --Format --Uniqueness
--I feel like I need a delete flag in the users table. Will you add it later? ――It's easy to do the migrate file of db, id to write all the time, and you don't have to specify the number of characters with varchar. --I am very relieved that the migrate file of db and the changes will remain in chronological order. In my previous job, I didn't even leave the SQL when I changed the DB.
Recommended Posts