単体テストコードで別のモデルのカラムを呼び出したい時
本日はテストコードをやっていました
結論他のモデルから特定のカラムを呼び出すためには、ストロングパラメーターの容量で欲しいカラムを記述する！
今回は、userとitemをuser_idとitem_idのカラムの形で欲しかったので
と記述しました
ここの内容はストロングパラメーターのマージでも使いました！
簡単にいうと、user_idが欲しいのでレコードの代表者のようなuserテーブルのidを元に作成しています！
ここのIDのレコードの代表者のような立ち位置と私なりに理解してからは、更にdbからの情報の取得と保存に関する考え方がわかってきたと思います！
単体テストコードで別のモデルのカラムを呼び出したい時
本日はテストコードをやっていました
結論他のモデルから特定のカラムを呼び出すためには、ストロングパラメーターの容量で欲しいカラムを記述する！
今回は、userとitemをuser_idとitem_idのカラムの形で欲しかったので
と記述しました
ここの内容はストロングパラメーターのマージでも使いました！
簡単にいうと、user_idが欲しいのでレコードの代表者のようなuserテーブルのidを元に作成しています！
ここのIDのレコードの代表者のような立ち位置と私なりに理解してからは、更にdbからの情報の取得と保存に関する考え方がわかってきたと思います！
dbのカラム名を間違えてました。。。。
今回は、久しぶりにテーブルを増やしました
結論、カラム名を間違えたのでrails db:rollbackコマンドを使用して修正しました！
READMEを確認しながら記述していたのですが、ヒューマンエラーは起こるものですね。。。
で、今回は作りたてだったのと練習も兼ねてrails db:rollbackを行いました
ただ、このコマンドを実行する前に確認していることがあります
それは、rails db:migrate:statusです
理由は、マイグレーションが本当に実行されているか確認したいからです
確認の内容は単純でマイグレーションがUPかDownのどちらかの表示になっているかチェックするだけです！
私は単純に、動いているか否かで考えています
今回は、rails db:rollbackを行いDownしたのを確認できたので、カラム名を修正再度マイグレーションを実行して完了でした！
authenticate_user!と move_to_の重なる時
ログイン関係に制限をかけるために今回活躍してくれました！
結論は、ログインの確認の役割をauthenticate_user!が代役してくれました！
move_to_とunlessを使ってログインしていてカレントユーザーでdbにすでに登録されているユーザー以外はお断りをするために使用しました
ですが、authenticate_user!を記述しているので、ログインもう少し掘り下げるとログインしているかの確認を先にしてくれます
なので、move_to_とunlessの中に記述しなくても先に記述しているauthenticate_user!が仕事をしてくれるので今回は楽できました！
ただし、ここでauthenticate_user!を先に入れないと機能してくれませんでした。。。
理由は、railsの上から下にデータを読み取る特徴によります
つまり、最初にログインの確認もしているauthenticate_user!が仕事をしてくれないとみんなこいつ誰？とエラーが起こりました。。。
Ruby on RailsのIDについて
本日は、削除機能や編集機能を実装しました
結論は、各レコードのIDの役割・活用方法がわかっていなかったです
私のMVCの流れのイメージは、dbからの情報を取得・保存するためのフィルターをM・Cが担っています
Vはdbから情報をM・Cを通して取得しブラウザに出力または、ブラウザから情報を入力されM・Cを通して保存していると思っています
更に、Mがdbからレコードの取得しその取得方法を記述しVがMのレコード情報からカラムの情報を取得していくとイメージしています
そんな流れの中で意識していなかったのが、IDの役割です
IDに関しては、よくよく考えるとストロングパラメーターで記述することもなければ、バリデーションをかけることもないのURLに入っている、正直あるのが当たり前すぎて役割について考えていませんでした
ですが、本日の実装でIDの存在が気になりました
理由は、何となしにデストロイのパスを探して記述し後ろに第一引数を入れるときにパスの存在が急に気になり出しました
そこから、検索してもイマイチな説明しかなかったのでメンターさんに疑問を投げ掛けました
私のIDに関してのイメージは、クリエイト時に作成されデストロイ時に消されるカラム達の代表です
この代表が、ストロングパラメーターやバリデーションに記述する必要がないのはdbに保存される時に生まれるからでした
存在が当たり前で、IDについて本当にわかっていませんでした。。。。
orderメソッドについて
今回写真の投稿の並び替えをしました
結論は該当するコントローラーにorderメソッドを記述するだけでした
内容はmodel.order("何のカラムか 昇順なのか降順 ")をインスタンス変数に入れるだけで済みました
今回ここに至るまでに、試しにviewに記述したり色々と試行錯誤してました。。。
しかし、レコードから何を出すかを記述しているのはモデルだと思い出したので検索をかけるとorderメソッドに行き着きました！
