Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

名前と時間が完全一致するイベントが (元のイベントを削除しても) 作成できない #543

Open
cp-20 opened this issue Jun 17, 2024 · 16 comments · May be fixed by #552
Assignees
Labels
bug Something isn't working feedback

Comments

@cp-20
Copy link
Contributor

cp-20 commented Jun 17, 2024

No description provided.

@cp-20 cp-20 added bug Something isn't working feedback labels Jun 17, 2024
@pasmophobia
Copy link

再現できないので、再現方法を詳しく書いてほしいです。

@cp-20
Copy link
Contributor Author

cp-20 commented Jul 3, 2024

あるイベントを立てて、消して、それとイベント名・開始時間・終了時間の3つが完全に一致するイベントを立てようとするとできないはずです

@pasmophobia
Copy link

pasmophobia commented Jul 3, 2024

再現できないです。それ以外(開催場所や主催グループ)が一致していなくても発生しますか?

@cp-20
Copy link
Contributor Author

cp-20 commented Jul 3, 2024

今確認したら、本番環境とステージング環境でDBスキーマが違っていて (events テーブルの UNIQUE(name, start_time, end_time) 制約)、本番環境でのみバグが起こるようになっていました

まずはステージング環境を本番環境に揃えるところからやってみると良いと思います👍

@pasmophobia
Copy link

pasmophobia commented Jul 3, 2024

わかりました🫡

@pasmophobia
Copy link

本番環境の制約をUNIQUE(name, start_time, end_time, deleted_at)に変更すれば治りませんか?

@cp-20
Copy link
Contributor Author

cp-20 commented Jul 3, 2024

そうするとイベントが作成できるが削除できないという現象 (= 削除時にUNIQUE制約に引っかかる) が発生しそうに見えますね👀

@ras0q
Copy link
Member

ras0q commented Jul 3, 2024

1回これを行ってrevertしたからかもです:bow:
むしろ本番環境のUNIQUEを一旦消してもらうのが良いです
#369

@pasmophobia
Copy link

そうするとイベントが作成できるが削除できないという現象 (= 削除時にUNIQUE制約に引っかかる) が発生しそうに見えますね👀

deleted_atにはそれぞれ違う時刻が格納されるので、そのようなことは起こらないのではないかと思います。あと、UNIQUEはNULLで重複するのを許容するらしいのでUNIQUEを残したまま直すとしたらそこをどうにかしないといけないです。

@cp-20
Copy link
Contributor Author

cp-20 commented Jul 3, 2024

deleted_atにはそれぞれ違う時刻が格納されるので、そのようなことは起こらないのではないかと思います

確かにそうでした:gomen: 普通に思い違いでした

@pasmophobia
Copy link

#369の内容をもう一回ステージング環境に実装し直してから上記の制約の変更をするか、本番環境から#369を消すかどっちにしますか?

@iChemy
Copy link
Contributor

iChemy commented Jul 3, 2024

普通に本番環境から消すってだけでいいんじゃないかしら

多分制約を消すためのマイグレーション用のコード書くだけで済む気がしている

@pasmophobia
Copy link

制約をつけた後revertしたみたいなので,本番環境にしか制約は存在しないと思います.本番環境から制約を消せばいいと思います.

@iChemy
Copy link
Contributor

iChemy commented Jul 4, 2024

@ras0q
これって 本番環境の DB を直接イジるのか
migration/v13.go を定義して制約を消すようにするの (できるかまだ確かめてない)

どっちが良いですか?

@ras0q
Copy link
Member

ras0q commented Jul 4, 2024

雑にやるなら前者、丁寧にやるなら後者ですね

多分ないけどtraPの本番環境で使ってるknoQと同様に、制約を追加する前からknoQをビルドして使っている人がいればその人も同じバグを踏んでいるはずなのでDBに直で入って消すよりはマイグレーションを書いて起動時に確実に制約を消す方が親切です

まあでも多分いないのでどっちでもいいです

@pasmophobia
Copy link

ワンチャンくらいは使ってる人いるかもしれないんで後者でやります.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working feedback
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants