maybe daily dev notes

私の開発日誌

MariaDBコントリビューション録その6 (完) - どのOSSにコントリビュートするのか

前回のあらすじ

MDEV-18873に取り組み中。これはクエリ内で指定されたperiodの名前が空文字列 (``) であるときに、MariaDBがクラッシュするというバグだ。

ALTER TABLE t ADD PERIOD IF NOT EXISTS FOR `` (s,e);

一旦自力で考察してPRを作成したが、レビュワーの指摘を受け推論に粗があることに気づく。さらに考察を深めよう。

tmokmss.hatenablog.com

考察する go deeper

これは2ヶ月前に取り組んだため、正直詳細は忘れてしまった。ざっくりとまとめる。

もともとは過程で呼び出される末端の関数にNULLチェックを入れていた。これはクエリの処理の中ではかなり後段での対処となるため、あまりにも対症療法的で、実は多くのバグを取りこぼすことになる。

より良い方法は、できる限り処理の前段でエラーにしてしまうことだ。結局の所根本的な問題はクエリ内の period name が想定しない文字列になっていることなわけで、これは period name として扱われるトークンを取り出せた時点で検証可能である。最終的にはクエリを字句解析する時に、period name となる文字列をバリデーションする形となった。

この考察をするにあたり、メンテナのニキータさん (@FooBarrior) からは以下の助言をいただいた (雰囲気で意訳):

  • 現象の根幹に当たれ。木を見て森を見ずのような状態に陥るな。
  • 他の類似処理 (今回はcolumn nameやtable name) でどうやっているのかを探れ。同じ解決策が適用できることも多いはずだ。
  • 既存のコードベースが長大だからといって読まない言い訳にはならない。適切な問題解決のためには徹底的なコードリーディングと深い考察が必要だ。

大変身に染みるアドバイスだった。今後同じような活動をしようとしている読者の皆様にもぜひ意識してみてほしい!ちなみに今回は、報告されているケース以外にも問題となるクエリを作ってみて、さらにそれらがなぜ問題となるのかをコードを追いながら考えることで、根本原因の吸い上げに成功した。いわゆる帰納法に近い考え方だろう。おそらく他のトラブルシューティングでも普遍的に有効な方法と思われる。

squash必要?

こぼれ話。MariaDBではPRを出す際にすべてのコミットを1つにまとめて都度 force push しながら修正していくことが求められている。 最後にGitHubでSquash mergeすれば良くない?と思うが、これはマージ前にメンテナが別ブランチでテストするときに1コミットだと都合が良いということ。

オールウェイズforce push

案外この規則を採るプロジェクトは他にもあるようで、例えば Ruby on Rails なんかもそう。rails/rails

force push運用は過去の作業・レビューログが消えるなどなかなか受け入れがたいが、素直に郷のしきたりに従うことをオススメする。 よほど今後もそのOSSにコントリビュートしたく、自分が現状を改善してやるんだという気概を持っている場合はその限りではないかもしれない。ただし、それを変えるには技術的なブロッカーがあるかもしれないし人的なブロッカーもあるだろう。茨の道であることは覚悟しなければならない。

完結

上記のようなやり取りをしつつ、途中2ヶ月ほど期間が空いてしまうこともあったが、無事 マージされたのだった 🎉

ちなみにこの検証中に関連する別のバグを見つけたが、それはレビュワーと話して今回のPRのスコープ外としてもらった。(ちょっとSQLの知識が足りなすぎてキツくなってきたのが本音… そもそも period 自体MySQLにはない機能なので、未だにあまりピンときていない) 直したいという方はこちら!

以上が今回のIssueの顛末。割と区切りも良いので、このシリーズは一旦ここで締めようと思う。最後にこれまでの(わずかばかりの)MariaDBへの貢献で考えたことをまとめる。

MariaDBにコントリビュートしてみて

今回MariaDBにコントリビュートしてみて良かったことは沢山ある。例えば

  • バグ修正はパズル的な要素があり面白い
  • C++の大規模コードに触れることが普段ないので新鮮
  • 普段触っているコードよりははるかに複雑なので、良い頭の体操になる
  • RDBMSの裏側をすこーーしだけコードレベルで覗けて、やや心理的な抵抗が下がった

ただ、少しつらいところもあって、こんな感じ。

  • SQLの標準に関する知識がないと自力で修正するのがキツい。そもそもどう直すべきかを決められないことも (今回だとperiod nameに求められる具体的な形式など。)
  • あまり知識のない自分に対してメンテナのレビューコストを割いてもらう申し訳無さ。パズルみたいで楽しー😆 なんて遊んでいる場合ではない。
  • 今の仕事とはやや縁遠い知識にはなるので、より趣味的な学習となる

ここらへんのPros Consは人によって全然変わるので、Prosが圧倒的に上回る人も多いはず!私にはMariaDBが最適というわけでもなさそうだなと感じたという話。

そんなわけで最近はめっきり普段使うソフトウェアにばかり手を付けている。特にAWS CDKは、以下の点でちょうど良い感じ。

  • 自分が慣れた技術スタックなのでメンテナに初歩的な手間を掛ける事は稀
  • 毎日使うツールなので、機能追加やバグ修正に直接利益がある
  • AWSOSSなので、業務時間に堂々と作業できる
  • CONTRIBUTING.md がよく整備されているので初心者でも迷わない
  • コミュニティ (cdk.dev) が活発で教え合いの交流が楽しい

github.com

色々なものに触れてみて初めてそれぞれの良し悪しが分かるという点もあるので、そういう意味でも今回の経験は良かった。ということで、MariaDBシリーズ完!引き続き趣味の開発は続けたいので、その一環で何かOSSにも関わる機会があればと思う。 おしまい