DBにデータを保存できるようにしましょう
TODO
- [x] Prismaのインストールと初期設定
- [x] VSCode: Prismaの拡張機能を導入 (Prisma.prisma)
既存のテンプレート・プロジェクト
- [x] https://github.com/joysofcode/sveltekit-deploy
- Full stack app
- DB: PostgreSQL + Prisma
- 本番環境はSupabaseでDBやログイン処理を行っている
- [ ] https://awesome-sveltekit.janosh.dev/
- SvelteKitを使った実例集
- https://github.com/janosh/awesome-sveltekit
- [ ] https://github.com/michael/editable-website
- sqliteを使っているがRDB系では最多のstar repoではないかと思われる
- ログイン機能も実装されている
- ディレクトリ構造は自分が想定したものに最も近く、シンプル
- [ ] https://github.com/guyromm/svelte-postgrest-template
- Svelte/SvelteKit + PostgREST + EveryLayout + social auth starter template
- PostgreSQL系を利用したrepoでは最もstarが多い
-
postgrestを利用すると楽にbackendが書けるらしい
- ORMが不要になる?
- ソーシャルログインもできるが、Svelte Ver3なので対応しているか不明
- ディレクトリ構造は割と複雑な印象 + .shがかなり配置されている
- [ ] https://github.com/dr-rompecabezas/sveltekit-prisma-postgres
- A full stack todo app built in Svelte, Svelte Kit, Typescript, Prisma ORM, PosgreSQL, and deployed to Vercel and Railway. Based on tutorial by Mike Nikles and coded in Gitpod.
- シンプルな構成
- チュートリアルだと思われるため、基本的な実装
- 2年前から更新されていないので、デプロイされたappが壊れており表示されていない
- [ ] SvelteKit, Vercel Postgres, Prisma, Lucia Auth, Skeleton UI, TailwindCSS
- https://github.com/rogadev/sveltekit-web-app-starter
- テンプレートプロジェクト
- [ ] https://github.com/TeemuKoivisto/sveltekit-monorepo-template
- 高い抽象化が図られている
- その分、他と比べるとプロジェクト構成はかなり複雑な印象
- [ ] https://github.com/aslink87/sveltekit-auth-template
- authの実装がメインのテンプレート + adminも実装されている + 部分的にDockerも使われている
- プロジェクト構成はReactっぽい
- [ ]
- [ ] Rust + Svelteの組合せ
- https://github.com/thiagovarela/consub
Supabase公式のサンプル https://github.com/supabase/supabase/tree/master/examples/user-management/sveltekit-user-management https://github.com/supabase/supabase/tree/master/examples/todo-list/sveltejs-todo-list
Supabaseの初期設定の例 https://note.com/shift_tech/n/n5191b5f19c9b
problems/{task_id}で保存するのは、TaskAnswerテーブルの認識で合っていますか? TaskAnswerテーブルに、atcoderのsubmission_idをつけるのはいかがでしょうか?提出のURL(https://atcoder.jp/contests/abc332/submissions/48364294 )の一番最後の数字です。 これを持っていれば、AtCoderの提出URLも作れるし(task_idと合わせ技)、 インポート機能も、ユーザIDをもとに、TaskAnswerテーブルにデータを入れればいいので、実装しやすいように思います。
@prettyhappycatty
problems/{task_id}で保存するのは、TaskAnswerテーブルの認識で合っていますか? はい!その通りです。
TaskAnswerテーブルに、atcoderのsubmission_idをつけるのはいかがでしょうか?提出のURL (https://atcoder.jp/contests/abc332/submissions/48364294 )の一番最後の数字です。 これを持っていれば、AtCoderの提出URLも作れるし(task_idと合わせ技)、 インポート機能も、ユーザIDをもとに、TaskAnswerテーブルにデータを入れればいいので、実装しやすいように思います。
とてもよさそうですね!!!
SubmissionStatusが独立したテーブルになっているのは、解答状況の種類と配色をアプリ全て実装しようと考えていた頃の名残です。
先日ご提案いただいたようにユーザスクリプトで解答状況の種類と配色をカスタマイズする方針が実現できそうであれば、submission_statusおよびatcoderのsubmission_idともにTaskAnswerテーブルにあったほうがシンプルでよさそうと思っています。
念のため確認ですが、提出idはどれか一つの解答と紐づけるという理解でいいのでしょうか? 複数の解答を残したい場合は、TaskEditiorial?テーブルのように別テーブルにしたほうがいいのかもしれないとも考えています。
@KATO-Hiro
念のため確認ですが、提出idはどれか一つの解答と紐づけるという理解でいいのでしょうか?
はい。そのイメージです。 つまり、TaskAnswerは、userId、taskIdに対して複数存在するのがいいのではと思います。 理由としては以下の通りです。 ・いろんな方針で解いたものを管理できる ・インポートした時に複数あったばあいにどれをインポートしていいかわからないが複数登録できれば判定不要で全部突っ込める。(インポート時の重複チェックにsubmission_idも使える) (もし、現状の仕様のように1つだけがいいなら、複数見つかった場合は最新だけAnswerに登録する・すでにAnswarが登録されていれば登録しない、という実現方法になるかなあ。)
複数登録を実現するには、/problemsの画面や、/problems/[task_id]の画面にも影響がありそうかなあと思います。 ・/problemsで表示されるデフォルトのステータス(TLA/WA・・・)を複数Answerのどれを表示するか?(最新の提出?) ・提出個数のサマリ(AC 1件・解説AC2件・WA1件・TLE3件、、、など)を表示するかどうか ・submissionIdを必須にするか?必須にできるか?(AtCoder本体に提出なしに管理したいことある?) ・/problems/[task_id]の画面で複数Answerの管理をする必要が出てきます。例えば左側20%くらいに一覧、選択すると右側に現在の表示で入力用のペインが出るようなイメージをしています。
先日ご提案いただいたようにユーザスクリプトで解答状況の種類と配色をカスタマイズする方針が実現できそう
この件ですが、userテーブルにicon_folder_urlを用意して、画像フォルダのURLを入れるのがユーザスクリプトより簡単そうに思います。(デフォルトは、https://raw.githubusercontent.com/AtCoder-NoviSteps/AtCoderNoviSteps/main/static/ns.png でいいような。) 個人的に作りたければ、pngのセットを作って、static/までのURLを入れられるようにするとページレンダリング時にできるので、ユーザスクリプトで更新タイミングを気にするより簡単かなあと思います。

(複数サブミッションつけられるとデータ容量やばいかしら、、、)
(複数サブミッションつけられるとデータ容量やばいかしら、、、)
けんちょんさんと要相談だと思いますが、1問あたりの提出数の上限を設定 + 一定の条件を満たしたら削除するのはいかがでしょうか? (本質的な解決にはもう少し工夫が必要そうです)
@KATO-Hiro
念のため確認ですが、提出idはどれか一つの解答と紐づけるという理解でいいのでしょうか?
はい。そのイメージです。 つまり、TaskAnswerは、userId、taskIdに対して複数存在するのがいいのではと思います。 理由としては以下の通りです。 ・いろんな方針で解いたものを管理できる ・インポートした時に複数あったばあいにどれをインポートしていいかわからないが複数登録できれば判定不要で全部突っ込める。(インポート時の重複チェックにsubmission_idも使える) (もし、現状の仕様のように1つだけがいいなら、複数見つかった場合は最新だけAnswerに登録する・すでにAnswarが登録されていれば登録しない、という実現方法になるかなあ。)
複数登録を実現するには、/problemsの画面や、/problems/[task_id]の画面にも影響がありそうかなあと思います。 ・/problemsで表示されるデフォルトのステータス(TLA/WA・・・)を複数Answerのどれを表示するか?(最新の提出?) ・提出個数のサマリ(AC 1件・解説AC2件・WA1件・TLE3件、、、など)を表示するかどうか ・submissionIdを必須にするか?必須にできるか?(AtCoder本体に提出なしに管理したいことある?) ・/problems/[task_id]の画面で複数Answerの管理をする必要が出てきます。例えば左側20%くらいに一覧、選択すると右側に現在の表示で入力用のペインが出るようなイメージをしています。
先日ご提案いただいたようにユーザスクリプトで解答状況の種類と配色をカスタマイズする方針が実現できそう
この件ですが、userテーブルにicon_folder_urlを用意して、画像フォルダのURLを入れるのがユーザスクリプトより簡単そうに思います。(デフォルトは、https://raw.githubusercontent.com/AtCoder-NoviSteps/AtCoderNoviSteps/main/static/ns.png でいいような。) 個人的に作りたければ、pngのセットを作って、static/までのURLを入れられるようにするとページレンダリング時にできるので、ユーザスクリプトで更新タイミングを気にするより簡単かなあと思います。
多面的な視点から仕様の不確定要素を考えていただき、ありがとうございます。
ユーザの便利さ ≒ 開発側の大変さみたいな部分はあると思いますので、スケジュール・予算などを踏まえて、ベターな方法にできるといいと思っています。
userテーブルにicon_folder_urlを用意して、画像フォルダのURLを入れるのがユーザスクリプトより簡単そうに思います
更新のタイミングが難しいのですね。承知いたしました。
プロフィール画像を表示できるようにする意味でも、専用のフォルダを用意したほうが良さそうですね。
@KATO-Hiro とりえあず、一通りの機能をという意味では、1対1でいいのかな。 answerテーブル作成と、submissionIdを属性として追加(1対1)で作ってみますね! status?(AC, WA, など、、、)も、submission_statusを外だしにしない場合はanswerテーブルに追加ですよね。 メモも置けた方がいいですよね。(個人的な希望)
保存の前に、コメントアウトされているユーザ情報を取得するのも一緒に優先して実装した方が良さそうな気がします。 (保存にユーザidが必要、、、)
#321 TaskAnswerの作成と保存について、新しいissueを作りました。
@prettyhappycatty
@KATO-Hiro とりえあず、一通りの機能をという意味では、1対1でいいのかな。 answerテーブル作成と、submissionIdを属性として追加(1対1)で作ってみますね! status?(AC, WA, など、、、)も、submission_statusを外だしにしない場合はanswerテーブルに追加ですよね。 メモも置けた方がいいですよね。(個人的な希望)
保存の前に、コメントアウトされているユーザ情報を取得するのも一緒に優先して実装した方が良さそうな気がします。 (保存にユーザidが必要、、、)
Issueの作成ありがとうございます!!!
-
最初はtask1対answer1で実装しておき、関連する未確定の仕様を決めてから1:多に拡張するのが良さそうだと思っています。 (この変更コストは高くつきそうでしょうか?)お願いしてもよろしいでしょうか?
-
けんちょんさんが想定されている解答状況(ラベル・配色・ラベル総数)をアプリ本体である程度柔軟に設定できるようにするためには、SubmissionStatusテーブル相当の属性が必要そうだと認識していますが、いかがお考えでしょうか?
-
解答にメモも紐付けたいですね。ただ、データ量の観点から文字数は多くても200〜500文字程度とかなり厳しめにしたいと思っています(1000〜1万文字書くなら、個人ブログに書いてリンクを貼った方がいいのでは?、と思っている派です)。
-
ユーザ情報と解答状況の関連づけは、破壊的な仕様変更がありpending状態でした。このタイミングで、実装すると良さそうです(現状、あべみさんに実装を完全にお任せしている状態となっているのに、私はコメントばかりで心苦しく思っております)。
@KATO-Hiro SubmissionStatus相当のテーブルも必要と思います! テーブルの属性は以下で作ってみています。 AnswersからはStatusidで参照しようと思います。
id label_name AC,NoSub、、、など。 image_path 画像のファイル名、ac.pngなど
詳しくは分割した方に書きます!