feat: add schema "public.speakers"

[toshick]

DB schema public.speakers

以下を想定

name	description
id	プライマリキー
name	スピーカーの名前
image_url	スピーカーのイメージ
caption	スピーカーのキャプション
description	スピーカーの説明
github_url	スピーカーのgithubのurl
x_url	スピーカーのxのurl
session_title	スピーカセッションのタイトル
session_description	スピーカセッションの説明
session_comment	スピーカセッション用コメント（デザインによる？）
session_time_from	発表時刻
session_time_duration	発表時間（min）
session_place	トラックの場所
session_doc_title	発表資料の名前（"発表資料"で統一？）
session_doc_url	発表資料のurl

created_at|
updated_at|

2023のデザイン

疑問

ユーザの基本情報（名前、ツイッタやGitHubのurl等）は auth.usersにつっこめるのか
できないとしたら public.users というものを別で作成し、authuserとuserとして分けて管理するのだろうか

スピーカーのユーザ情報はこのテーブルに含めることにした

[netlify]

✅ Deploy Preview for vuefes-2024 ready!

Name	Link
🔨 Latest commit	d0d8b4d
🔍 Latest deploy log	https://app.netlify.com/sites/vuefes-2024/deploys/666701c85afe4300083feef2
😎 Deploy Preview	https://deploy-preview-139--vuefes-2024.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jiyuujin]

気になったこと

1. speaker_ 全て不要では？
   speakers に入っている時点で、基本全てスピーカーの何かになると思います
   （外部キーなど他から持ってくる場合は、何かしら付ければ良さそうです）

2. user_id は不要では？
   speakers の用途は、スピーカーの表示・スタッフによるスピーカー情報の更新で
   各スピーカーは、それらのデータが更新された時点でログインする訳では無いと思うので、それは不要かと

=====

ユーザの基本情報（名前、ツイッタやGitHubのurl等）は auth.usersにつっこめるのか

各スピーカーにログインして入っていただければ、自動的に auth.users へ基本情報となるデータが入ります
ここでいう基本情報となるデータは GitHub のアイコン画像に使っている URL とか、GitHub で設定されている名前を指しており、それを拡張するなら昨年の public.event_users にスキーマ構成を近付ける必要はありそうです
-> 今回の speakers の用途を考えると、そもそも各スピーカーにログインしてもらう必要は無いのではと

[toshick]

speaker_ 全て不要では？
speakers に入っている時点で、基本全てスピーカーの何かになると思います
（外部キーなど他から持ってくる場合は、何かしら付ければ良さそうです）

わたくしはわかりやすく冗長なほうが好きなのでこうしています
ですが決めの問題なので省略でも問題ないです

[toshick]

speakers の用途は、スピーカーの表示・スタッフによるスピーカー情報の更新で
各スピーカーは、それらのデータが更新された時点でログインする訳では無いと思うので、それは不要かと

このPRにもはっているスピーカー情報のページを表示するために、リレーションが必要かなと考えています

1. このページに来る
2. スピーカーの情報をsupabaseから取得
3. スピーカーセッションのタイトル、説明、スピーカー本人の情報を出力

各スピーカーは、それらのデータが更新された時点でログインする訳では無いと思うので

ここの意味がよくわかりませんでした
スピーカー本人の名前やsnsのリンクなどはどうやって取得するのでしょうか
それとも speakerのDBにはデータを格納するけども、スピーカの詳細ページではそのデータを使わないのでしょうか

[toshick]

スピーカーのユーザー情報は別テーブルにせず、スピーカーテーブル内に含めることにする
セッションの情報とスピーカーの情報が混在するので接頭辞は必要だと判断
session_ を追加した

[jiyuujin]

ASK
国際化対応、どう折り合い付けましょうか？
それぞれのカラムに ja/en を設ける案 (name -> name_ja / name_en) が無難ですかね

（i18n キーを入力させる案も無くはないが、更新の度にそれぞれの json ファイルを更新するのも面倒臭いですよね

[toshick]

jaとenを追加してみました
eb96786

[jiyuujin]

あと、スピーカーのアバターURL、考慮されていますかね？

もし Storage のお世話になるなら、それはスポンサーのロゴ画像と共同で使えば良いと思います mm

[cloudflare-workers-and-pages]

Deploying vuefes-2024-designsystem with    Cloudflare Pages

Latest commit:	d0d8b4d
Status:	✅  Deploy successful!
Preview URL:	https://4dcb5bb7.vuefes-2024-designsystem.pages.dev
Branch Preview URL:	https://feat-schema-speakers.vuefes-2024-designsystem.pages.dev

View logs

[toshick]

スピーカーのイメージを image_urlとして追加

[jiyuujin]

ASK

image_url には何を入力する想定ですか？

• public 配下に画像を入れる前提で、image_url にパスを入力する
  • ex: /public/gihyo.png (some path) or gihyo (file name only)
• Storage に画像を入れる前提で、image_url にパスを入力する
  • ex: https://supabase.com/ .. (full path)
• public 配下でもない、Storage でもない、第3の候補で？

-> 2番目なら前から言っている通りそれを構築するためのクエリが必要かなと思います mm
#142 (comment)

=====

Storage Bucket の設定（以下 2023年の例

create policy "Avatar images are publicly accessible."
  on storage.objects for select
  using ( bucket_id = 'avatar' );

create policy "Anyone can upload an avatar."
  on storage.objects for insert
  with check ( bucket_id = 'avatar' );

[toshick]

アバターバケット用の設定を追加しました

[jiyuujin]

ちなみに追加いただいた bucket は、アバター用画像のみが入る想定でしょうか？

もうひとつの PR でスポンサーのデータベースもやってもらっていますが
スポンサー画像はまた別で bucket を作るお考えで齟齬は無い？

（もし、bucket は同じ場所の方がという考えでしたら、bucket_id は Avatar からリネームいただいた方が良さそうです

[jiyuujin]

上の認識に齟齬等なければ、ざっくり LGTM です

（引き続きツッコミ多くてすみません mm）

ひとつ気になるのは、ほとんどのカラムに NOT NULL 制約がついている点です
NOT NULL 制約が入っている以上、何か追加なり更新しようとすると、それらは全て必須扱いとなります

また、登壇スライドの URL (session_doc_url) をはじめ、スピーカーの先行公開の時点でそれらが判明することはなく、長くかかったとして 10月まで判明することは無いと思います

=====

運用として「TBD」と書くことを勧める方法があり、表示側の制御で「TBD」チェックが必要になります
空白値を許容する設計を取るなら、null チェックで間に合います
その差、どちらを取るかですね

（どちらが正解ってことはありませんが、齟齬ありませんかというご確認でした mm

[toshick]

not nullが必要か、なにかしら邪魔をするのか、バケットの運用設計などすべてこのPRの作成段階でやるのは難しいのでとりあえずマージして修正を別PRでやるのがよいと思います

今のところとくに設計はしていません
全体を設計するならば他テーブルも含めて一つのPRでやるほうがよかったでしょう
なので齟齬というものは存在しないです。

[toshick]

ためしにアップロードしてみた画像（有効期限1年のurl）380文字
https://jjdlwtezpdclgxxagxpj.supabase.co/storage/v1/object/sign/sample/images/main-b4f355e2-e5a4-4a11-89dc-95142deaefce.png?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJzYW1wbGUvaW1hZ2VzL21haW4tYjRmMzU1ZTItZTVhNC00YTExLTg5ZGMtOTUxNDJkZWFlZmNlLnBuZyIsImlhdCI6MTcxNzg1NTQ5MywiZXhwIjoxNzQ5MzkxNDkzfQ.jBi9px7ec8F9RP18eEwX7RGL3PMxfmiEjwG4iAFvhqw&t=2024-06-08T14%3A04%3A53.669Z