search

terakura-aina / Date_me

デートセッティングアプリです
7 stars 1 forks source link

「今日のミッション」に完了ステータスをつけたい #16

Closed terakura-aina closed 3 years ago

terakura-aina commented 3 years ago

■実現したいこと■ デート当日にミッションが送られてきたら一覧が見れるページで、それぞれのミッションに完了ステータスをつけたい 【画面遷移図】 https://xd.adobe.com/view/1720b733-f087-4b61-a494-12e01cba8629-4273/screen/d8d4e19c-8a73-4d73-81ca-3b3fe97b334f Image from Gyazo

■現状■ today_missionsテーブルでschedule_id,invited_mission_id,partner_mission_idを紐付けて「今日のミッション」を管理している(１つのレコードに、２つのミッションが紐づいている状態) →ここにinvited_mission_statusとpartner_mission_statusカラムを追加し、ステータスを管理すればいい？

■懸念点■ today_missionsテーブルの１つのレコードに誘った人、誘われた人へのミッションがどちらも含まれていると複雑な構造になってしまうのと、バグが起こった際にも原因の解明がしずらくなる

■改善案■ today_missionsテーブルは一つのミッションと紐づく構造にする (今までのテーブル設計→ミッション第一弾が送られる→today_missionsのレコードが１つ増える 改善案のテーブル設計→ミッション第一弾が送られる→today_missionsのレコードが２つ増える) 【ER図】 https://app.diagrams.net/#G1AGXLePP-HWYbJKf-u2P9vBgifvpB9Tbj Image from Gyazo

このようにテーブルの構造を変更して進めていこうかと思っています。 改善後のテーブル構造で懸念点などないか、ご確認いただきたいです。

terakura-aina commented 3 years ago

変更後のテーブル設計で既存の機能に生じる変更作業 →rakeタスクの中でtoday_missionsのcreate作業をinvited用とpartner用２つ分createする →ミッション一覧を確認するページの表示のための記述の変更

想定しているのはこの２点で、変更することにより大きな作業が発生することはなさそうです。

yuji91 commented 3 years ago

こちら変更前のER図です。 Image from Gyazo

DaichiSaito commented 3 years ago

today_missionsにuser_idっていう外部キーがあるんですが、make_plansテーブルに紐づいてるのは間違いかな？make_plan_idになるべき？

DaichiSaito commented 3 years ago

変更後ので良さそうな気がしますねー。

仕様の話なんですが、夫婦お互い同じミッションが課されるんですかね？もしそれぞれ違うミッションが課されるのであれば変更前のだときつそう。inviter_mission_idもしくはpartner_mission_idのどちらか片方はnullになるっていう設計になると思うのでデータ不整合が起こりやすい気がする。

terakura-aina commented 3 years ago

紐付け方がいまいちわからなかったのですが、 TodayMission.cretateするときに、make_plansテーブルに保存されているinvited_id,partner_idを通してuser.idを取得する、という意味で上記のように紐付けました。

仕様の話なんですが、夫婦お互い同じミッションが課されるんですかね？もしそれぞれ違うミッションが課されるのであれば変更前のだときつそう。inviter_mission_idもしくはpartner_mission_idのどちらか片方はnullになるっていう設計になると思うのでデータ不整合が起こりやすい気がする。

ランダムなので基本は違うミッションが課され、たまに同じ可能性もある、といった感じです。 私が考えていた方法だと、ミッションをそれぞれ生成し、その後同じタイミングでTodayMissionsテーブルの１つのレコードに２つとも保存していたのでnullにはならない仕様でした。 しかし、完了ステータスを実装したいと考えた時に、テーブルの構造が複雑になってしまうとのことだったので、問題なさそうであれば変更したいと思っています。

terakura-aina commented 3 years ago

user_idにはmake_plan_idではなく、user.idを入れたいと考えています。 usersテーブルのidと紐づけるべきでしょうか？

yuji91 commented 3 years ago

user_idにはmake_plan_idではなく、user.idを入れたいと考えています。

today_missionsテーブルのuser_idについてですかね、そうであれば以下のようにモデル名も記載することでどのテーブルの話かがズレることなく伝わると思います（カラム名だけだといくつか候補があるので） TodayMission.user_id

usersテーブルのidと紐づけるべきでしょうか？

はい。TodayMission.user_idにはUser.idが対応しているカラムだと思います。 しかし変更後のER図ではTodayMissionとUserではなく、TodayMissionとMakePlansがアソシエーションの関連を示す線で繋がっていると思います。

こちらは変更前のER図でTodayMissionにinviter_user_idとpartner_user_idが残っていた名残で変更されていない部分かと思われるので、こちらも併せて変更する必要があると思います。

terakura-aina commented 3 years ago

today_missionsテーブルのuser_idについてですかね、そうであれば以下のようにモデル名も記載することでどのテーブルの話かがズレることなく伝わると思います（カラム名だけだといくつか候補があるので） TodayMission.user_id

TodayMission.user_idについてです。 確かにカラム名だけだとわかりずらいですね…モデル名も記載するようにします。

Image from Gyazo このように解釈したのですが、問題ないでしょうか？

terakura-aina commented 3 years ago

勘違いしていることに気がつきました。 Image from Gyazo

スケジュールと紐づいているuser.idを取得したいため、その場合はmake_plan.idと紐づければそれが取得できると思うので、上記のアソシエーションが正しいでしょうか？

yuji91 commented 3 years ago

ミッション一覧ではtoday_missionの一覧を表示すると思うのですが、ログインユーザ自身に割り当てられたミッションを絞り込んで表示すると思うので、TodayMission.make_plans.invited_id == current_user.idのような比較になってしまうと思います。

またtoday_mission.make_plans.partner_id == current_user.idの比較も併せて必要になりそうな感じがするので、

以下の状態のuser_idのみ持っている形であればtoday_mission.user_id == current_user.idとシンプルな比較で済むかと思います。 https://github.com/terakura-aina/Date_me/issues/16#issuecomment-781991469

ミッション一覧で表示するミッションが招待された側 or 招待した側として識別しながら表示する必要は特にないと思うので、user_idがあれば十分な気がしますね。

DaichiSaito commented 3 years ago

スケジュールと紐づいているuser.idを取得したいため、

ここの意図ってなんでしたっけ？

terakura-aina commented 3 years ago

以下の状態のuser_idのみ持っている形であればtoday_mission.user_id == current_user.idとシンプルな比較で済むかと思います。

ページを開いた瞬間はuser情報が取得できておらず、current_userメソッドが使えない(current_userがnullになりエラーになってしまいます)のですが、 ミッションを送る段階でそのミッションはinvited_user宛てか、partner_user宛てなのかはわかっているため、現在のテーブル設計の場合にはなりますが、

https://liff.line.me/1655665365-robLXJ1P/missions/#{schedule.token}/invited

開いてもらうURLにinvitedもしくはpartnerと情報を持たせ、

-if params[:user] == 'invited'
      - @schedule.invited_missions.each do |mission|
          tr
            td.px-4.ml-2.p-2.wf-kokoro = mission.body

    -if params[:user] == 'partner'
      - @schedule.partner_missions.each do |mission|
          tr
            td.px-4.ml-2.p-2.wf-kokoro = mission.body

paramsでinvitedの場合は@schedule.invited_missionsのように条件分岐させてinvitedのミッション一覧/partnerのミッション一覧を表示させています。

テーブル設計が変わった場合の条件分岐の方法がまだ思い付いていないのですが、current_userメソッドが使えない場合でもuser_idのみあれば問題ないのでしょうか？

terakura-aina commented 3 years ago

スケジュールと紐づいているuser.idを取得したいため、 ここの意図ってなんでしたっけ？

一つ上のコメントで内容を記述したのですが、current_userメソッドが使えない場合にinvited_userなのかpartner_userなのかを区別するには、make_plansテーブルにあるinvited_id/partner_idカラムで判断できると思ったからです。

terakura-aina commented 3 years ago

Image from Gyazo user_idをusersテーブルのidと紐付け、新たにuser_statusカラムを追加し、user_statusカラムでinvitedなのかpartnerなのかを区別するようにしたところ、完了ステータスを実装することができました。

ただ、ログを確認するとデータ上ステータスは変わっているものの、リロードしないと完了/未完了のボタンが更新されないため、こちらは新たにプルリクをあげて質問させていただきます。