お知らせとプルリクエスト
はい、こんにちは。第17回のtanaken on Railsです。
今週のThis Week in Railsから、3つのトピックを紹介します。
1つ目は、RailsWorld2024に関するお知らせです。
チケットが、米国東部サマータイムで、4月30日の13時から販売開始になると。
日本標準時では、5月1日の深夜2時からチケットが販売開始するので、
参加される方はチケットを購入してくださいね、というお知らせでございます。
続いて2つ目、プルリクエストの紹介ですね。
タイトルが、ensure pre 7.1 migrations use legacy index names when using rename table、というプルリクエストです。
マイグレーションのバージョンごとの挙動変化
こちらは、アクティブレコードに関する変更です。
マイグレーションで、テーブルの名称を変更したいとき、 rename table メソッドが使えます。
Rename table を実行すると、インデックスの名前もリネームされます。
例えば、Posts というテーブルを作ったとしましょう。
Create table Posts do end で、ブロックの中では、
ストリングでタイトルというのを定義して、インデックスタイトル、タイトルのインデックスを貼ると。
そんなテーブルがあるとしましょう。
この Posts テーブルのインデックスを確認してみると、
アクティブレコード、コロンコロン、ベースドット、コネクションドット、インデックシーズ、
ベースドット、インデックシーズ、カッコで、テーブル名を指定して、
インデックスの複数形ですね。
インデックシーズ、カッコ、ポスト、テーブル名をやると、
テーブル名に貼られているインデックスが一覧で見れるんですけど、
その一覧で見れたインデックスの一つ目のネームを確認してみると、
さっきタイトルにインデックスを貼ったので、
インデックスの名前は index underscore post underscore on underscore title
index post on title というインデックスが作られます。
この Posts というテーブルをリネームしてみましょう。
ロングテーブルネームという変数を定義してみて、
例えば a という文字列を60回繰り返した a というテーブル名にリネームしてみようと。
リネームテーブル Posts Long Table Name という形でリネームしてみましょうと。
リネームしてみると、リネームした後にインデックスを確認してみると、
インデックスは index underscore a が60回、
underscore on underscore title というインデックスに変更されます。
つまり、さっきインデックスの中で Posts となっていたところが a に書き換わるということですね。
こんな感じでインデックスの名前が変わるというのが、
今の挙動ですと。
ただ、これ今の挙動と言ったんですけど、これが Rails 7.0 系の時の挙動ですね。
Rails 7.1 系では、インデックスの名前のフォーマットが変わってます。
具体的に何かというと、インデックスがすごく長くなってしまった場合に、
インデックスの名称を短縮版で自動で生成するという仕組みになっています。
より具体的に言うと、インデックス名のバイトサイズが 63 以上の場合は短くすると。
短くってどんな短くなるのかというと、
IDX アンダースコア オン アンダースコア カラム名を配分でつない合わせたもの、
さらにそれにハッシュアイデンティファイヤーという、
元々短縮版じゃない方のインデックスの名前になるはずだったものを、
オープン SSL コロンコロン ダイジェスト コロンコロン SHA256 シャーニゴロー
シャーニゴロー.ハッシュダイジェスト 元々インデックスになるはずだったテーブル名を
つまりハッシュの文字列を生成して、その文字列の .first 10 なんで、
元々の超長いインデックスになるやつだったはずのやつを暗号化して
最初の10文字を取ってきたやつというのをマツビに書き加えると。
つまりどんな感じになるかというと、めちゃめちゃ長かったやつが
IDX 今回の場合だと IDX on title underscore hash
ハッシュの文字列10文字というようなものになると。
なのですごい長いテーブル名の場合も、インデックスを貼ると
そういう短いバージョンのインデックスになるというので便利だねという変更が加わっているんですよ。
今回のプルリクエストは何かというと、
マイグレーションのファイル、そもそもマイグレーションのファイルってバージョンを書いてると思うんですよ。
マイグレーションファイルの先頭にね。
マイグレーションクラス、アクティブレコードコロンコロンマイグレーションクラスというのがあって
それにブラケットでバージョンを指定することができるようになっていますよね。
マイグレーションファイルにみんなブラケット7.0とか7.1とか
昔のものだったら6点いくつとか書いてあると思うんですけど。
それの7.0でマイグレーションをやったときはなぜバージョンの番号が書いてあるかというと
そのマイグレーションファイルの挙動が昔の当時のバージョンのロジックに沿って実行されるようになっていてほしいから
マイグレーションファイルのクラスにレールズのバージョンが書かれているわけですわ。
今回何が問題かというと7.0系のときに作ったマイグレーションファイル
そのときはインデックスを貼ったらクソ長いテーブル名の場合はクソ長いインデックスになっていたわけですわ。
7.0って書いてあるにも関わらず今回最新のレールズでリネームテーブルをやると
インデックスの名称が7.1の最新のレールズのロジックに沿ってリネームが行われちゃう。
さっきの例だとインデックスポスツオンタイトルというのが元々のやつで
すごい長いテーブル名にしたときにはリネームするとさっき紹介したようなインデックス-a-a-a-a-a-a-aが60個のオンタイトルというインデックス名になっていたんですけど
それが7.0系のときの挙動だったんですけど
今その時点でそのレールズアプリケーションで動いているバージョンが7.1のレールズで動いているときにそのマイグレーションを実行すると
マイグレーションファイルは7.0って書いてあるのに
インデックスのリネームは7.1の仕組みで短縮形でインデックスが作られてしまうと
なのでマイグレーションファイルの中にリネームが含まれている場合に
7.1系で動かしたときと7.0系で動かしたときでインデックスの名前が異なる場合があると
これ自体何が問題かというと
いまいちプレリクエストにもしっかりと書いてなかった
差が出ちゃいますよって名前が変わっちゃいますよと書いてあったんですが
これが具体的に何が問題になるのかというのは僕の想像なんですけど
例えば複数の開発者で同じレールズアプリケーションを開発していて
7.0のときから環境を作っていたエンジニアは
当時マイグレーションしたので7.0のときにマイグレーションしてたので
すごいクソ長いインデックスになっていると
だけど新しい人が入ってきて環境を構築すると
例えば7.1系で動いているレールズアプリケーションの状態でマイグレーションすると
同じテーブルなのにインデックスの名前が
もともと言ったAさんと後から入ってきたBさんとで
インデックスの名前が変わるみたいなことが起こるようなとは思ったんですよね
でもそれがすごい問題かというと
実際はそんな問題ないと思うんですけど
一応そういう差は出そうだなというのは感じました
本番のアプリケーション関連で言うと
何だろうな
今AさんとBさんみたいな理屈で
後出しで何かレールズマイグレーションのコマンドを打って
テーブルを何か作っていきたい
例えば何だろうな
レプリケーションでも違う
マルチDBとかにするときに
新しく作る方のDBにマイグレーション実行すると
1個目のDBと2個目のDBでインデックスの名前が変わっちゃうとか
はあるかな
とは思いましたけどね
インデックスの名前が変わっていてアプリケーションで
そんなに実際レールズアプリケーションを動かしていて
DBに貼られているインデックスの名前が何なのかとかって
あんま気にしなくていいようになっているので
大抵はね多分
そんな問題になるかというと僕はちょっと分からないんですけど
でもそういう差分が出ちゃって
あんまり嬉しい状態じゃないだろうなというのは
なんとなく分かりました
今回のプレリクエストでは
マイグレーションファイルのマイグレーションクラスが
7.0と指定されていたら
それは7.0の当時の
リネームの
インデックスの名前フォーマットに従って
動いてくれた方が嬉しいよねということ
だというふうに理解しました
という感じですね
ちょっと長くなりましたが
最後3つ目
ヘックスバイナリパーサーの追加
3つ目はプレリクエストのタイトルが
Support Hex Binary Type in XMLというものです
こちらはアクティブサポートに関する変更です
このプレリクエストでは
XMLにヘックスバイナリパーサーを追加しています
ヘックスバイナリというのは何かというと
XMLのプリミティブデータ型の一つ
ということですね
w3.orgのページをリンクを貼っておいたので
ヘックスバイナリ自体については
そちらをご覧くださいという感じですね
はい
よし そんなところで
今週のたなけんおんレースは以上となります
はい ではまた来週
バイバイ
