[Session] セッションやキューを読み書きするリポジトリを実装

[p1ass]

概要

セッションやキューを読み書きするリポジトリを実装する。

要件

すこし重たいので、テーブル設計とrepositoryの実装でPRを分けたほうが良いです。

• IDを指定してセッションを取得できる
  • 基本情報
  • セッションの作成者
  • 現在の再生状況
• 新規でセッションを作成できる
• キューに曲を追加できる (削除はできなくてよい)

API仕様

API仕様をみつつ必要なデータベースのカラムを考える。

• https://github.com/camphor-/relaym-server/blob/master/docs/api.md#post-sessions
• https://github.com/camphor-/relaym-server/blob/master/docs/api.md#get-sessionsid

タスク

• テーブル設計

[p1ass]

これtrack情報を何処までDB側に保存するか悩むな

[sanposhiho]

一旦テーブル設計のレビューお願いします

[p1ass]

• SMALLINT使ってる部分あるけど、結局アプリケーション側ではint32で扱うのでINTのままでも良いかなぁって思いました！データサイズ削減以外になにか理由ってある？
• あんまり記号の意味が分かってないんだけど、tracksののプライマリキーってuriであってる？もしそうだとすると、「ある曲は一つのセッションにしか属せない」状態になってしまって、このWebサービスを通して1回しかその曲を再生出来ない状況になりそうだなぁと思いました。

[sanposhiho]

結局アプリケーション側ではint32で扱うのでINTのままでも良いかな
データサイズ削減以外になにか理由ってある？

🙆‍♂️
特になかったです

もしそうだとすると、「ある曲は一つのセッションにしか属せない」状態になってしまって

脳死でuriをPKにしてたんですけど、確かにそうですね…直しておきます

[sanposhiho]

すこし重たいので、テーブル設計とrepositoryの実装でPRを分けたほうが良いです。

っていうのはSQLとrepositoryでそれぞれ別のPR出した方が🙆‍♀️ってことであってますか？

[p1ass]

意図としてはリポジトリの実装をしてからテーブル設計のやり直しをすると手戻りが大きいので、途中でレビューを挟みたいという意図だったので、このままテーブル設計をissue側で議論するなら特に分けなくても大丈夫です！🙆‍♂️

[sanposhiho]

結局スクショだけだったらわかりにくい部分もあるかなって思ったんでいったんPR出しましたー🙏

[p1ass]

一旦終わったのでcloseします。
Thx @sanposhiho ！