scaffold
MVCアーキテクチャではmodel,view,controlerが組み合わさって一つのリソースと考える。scaffoldを使うとリソース単位で自動生成してくれる。
scaffoldをしてサーバーを立ち上げると、その時点からuserリソースを扱える。/users/newとかできる。
migration file
これはrailsとDBが全く別物だから、migration fileに書いて〜を保存するスペース作ってくれない？とお願いをしなければいけない。なので、rails generate scaffold User name:string email:stringなどの指示を出した後はrails db:migrateをしないとDBにリソースを保存することができない。ちなみに、rails db:migrateをせずにrails sをすると、 migration pending(DBに何かお願いすることあるんじゃないの？）というエラーを出してくれる。rails db:migrateはべきとうせいである。つまり何度実行しても追加したmigration fileがなければ何も起こらない。
resources
これはルーティングのパッケージ版。本来 /users => user#indexなど基本のルーティングがパッケージングされてる。
actionのデフォルトview
例えばindexアクションを呼び出した時、renderなどのviewを呼び出す指示が書いてないことがほとんど。その場合は、アクション名からapp/views/users/index.html.erbが呼び出される仕組みになっている。
indexアクションの場合。
後半戦
bundle exec
このコマンドはgem fileを読み込んだ上でexec以下のコマンドを実行するというもの。 ex)bundle exec rails --version
テーブルの関連付け
class User < ApplicationRecord
has_many :microposts
end
class Micropost < ApplicationRecord
belongs_to :user
validates :content, length: { maximum: 140 }
end
これによって、User.first.micropostsなどが実行できる。
そもそもなんで上記のコマンドでテーブルが結合される？
これはrailsのデフォルトによるもの。
micropostsテーブルにはuser_idというカラムがある。
model名_idというカラムがあり、結合すると、model名（ここではusersテーブル）のidカラムと自動的に結合してくれるから。
validation
class Micropost < ApplicationRecord
validates :content, length: { maximum: 140 }
end
これによって投稿の文字数を140文字に制限することができる。
heroku注意点
上記のようにテーブルを作った状態でherokuにアップしようとすると、エラーになってしまう。
それはmigrationfileが開発用には適用されたが、本番環境では適応されていないから。開発環境用のDBと本番環境用のDBが違うことから起きる。
そのため、 heroku run rails db:migrate としてあげる。
つまり、migrationfileを一つでも作ったら、git push heroku masterをした後に上記のコマンドを実行しなければいけないということ。
また、DBは違えど、Active RecordによってSQLが適切に書かれるのでそこを気にする必要はない。