@abcang じゃあ対応しときますか…
@abcang
個人的には普段からkotlinでtextNullable?.isNotEmpty() == true とか textNullable?.isEmpty() != false とかが日常になってるので3値論理を回避する理由は特にないのですが、mastodonの人たちがどうなのかはよく知りません
@abcang まあ今回それを行う積極的な理由はないと思うのですよね…。migrationが重くなるだけ
@abcang change_column_default :mentions, :direct, false してもDBのカラムにはデフォルト値は設定されないですね。alter table mentions alter column direct set default false; みたいのが走るかと思ってたらそんなことはなかった。なので結局クエリを書く時は3値論理の考慮を強いられるみたいです。
@abcang PRを更新してみました。手元の環境でrollbackとmigrateを行って、直後にpsqlで select direct,count(0) from mentions group by direct; してdirectカラムの初期化が行われていることを確認済みです
@abcang 前提が違うみたいなんですが、あのupdateは全件に対して働く訳じゃなくて、visibility=3のstatusesに対応するmentionsだけをupdateするやつですよ
@abcang add_columnのタイミングでnull:falseしたり非nullなデフォルト値を設定したりするとstrong migrationになっちゃいますね。テーブル全体書き換える重い奴です。add_columnした後にデフォルト値を設定する程度なら書き換えずに済むみたい
https://github.com/tootsuite/mastodon/pull/7614 は落ち着いたので査収おねがいします…
PREPARED_STATEMENTS=false をせずにそのまま使ってるタンスって結構あるのかな。…あるんだろうなあ…
5xxなのは良いとして、503以外のエラーを返すようにすればいいのでは。あとは監視系で工夫すればよさそう
where() にただの文字列を渡せば定数のまま取り扱ってくれるかというと、そんなことはなかった…。
masterでlightテーマが復活してますが、ミュート確認ダイアログの色がひどいことになってます
というか即値部分まで勝手にbind parameter化するのはRailsの暗黒面だな…
コードから個別にprepared statement を無効化するには to_sql した後で unprepared_statement で囲む必要があるらしいが、今のコード構成だとやりづらい感じあるな…
postgresqlのlog_statementをいじって確認したんですけど、Railsってクエリ中の定数パラメータ(where visiblity=3 みたいなの) を prepared statement のためにbind parameter 化するんですよ。そしてPostgreSQLはbind parameterに関しては部分インデクスの利用を行ってくれないのです。.env.production に PREPARED_STATEMENTS=false って書いとけばこの現象は起きません。pgbouncer導入してる人は既にこうなってるはず。