SQLFluffのVSCodeの拡張機能を気軽に試せるようにしてみました
はじめに
SQLFluffって気になっているけどpythonが必要だったりして、なんかWindows環境を汚しちゃいそうで気軽にお試しにくいよなぁと思っていたので、Dockerを使って気軽に試せるようにしてみました。
特にめんどくさいのはdbtとセットで使うときにはdbt compileが中で動く（incrementalとかあるからprofileを参照して接続しに行く）ので、接続先が必要になるというところ。PostgreSQLのコンテナをセットで起動するようにしているので、もう至れり尽くせりかと思います。（jinjaのテンプレートでやればいいというのはいったん置いておきます笑）
とりあえずGitHubに資材は置いておくので興味のある方は使ってみていただければと思います。Dockerfileとかあるので本気で使うぞとなったら、自分好みの環境に作り替えられると思います！
ルールについて
初めて使ってみる人も多いと想定するので、SQLFluffのルールに関して真面目に整理してみようかなと思います。
前提知識
Ruleの持つ4つの共通要素
SQLFluffにおけるルールは以下の4つの要素を持っています。
| 要素 | 説明 | 例 |
|---|---|---|
| rule code | ruleのID | LN01 |
| rule name | ruleの名前 | layout.indent |
| rule alias | ruleの別名で非推奨になったIDであることが多い （おそらく後方互換性のために残っていると想像） |
L003 |
| rule group | ruleのグループ | layout や capitalization |
各ルールについて
一部は試せていませんが、内容をまとめているのでよかったら参考にしてください。
ルールの指定方法
大きく2種類あります。
-
.sqlfluffファイルに記載する方法 .sqlfluffファイルに記載する方法 - 各SQLファイルごとに記載する方法 各SQLファイル後に記載する方法
個人的には.sqlfluffファイルに共通の設定を持たせてチームで共有する形が理想なので、git管理にしてワークディレクトリに配置しておくのがいいかなと思います。
適用するルールの指定方法のプラクティス
コードや名前やエイリアスやグループを利用することで適用するルールや除外するルールを制御することができます。
また、プロジェクト全体で適用するルールと個別のファイルに対して除外するルールを上書きすることができるので、設定ファイルの書き方の大まかな方針は以下の2つのパターンがあるので、どっちがいいのか決めて適用していくといいでしょう。
- 【適用リストパターン】適用するルールのみ指定する
- Pros：どのルールが有効になっているかわかりやすくなる
- Cons：新しいルールは能動的に適用する必要がある
- 【除外リストパターン】マスター側の設定でルールを指定したうえで、適用したくないルールを個別のプロジェクトのサブの設定ファイル内で例外として設定する
- Pros：継承される値が絞れてシンプル。新しいルールの適用もシンプル。
- Cons：例外の設定などが煩雑。どのルールが有効なのかわかりにくくなる
個人的には除外リストパターンで除外するリストを.sqlfluffファイルに記載して、個別のSQLファイルで追加設定していく方が理想です。
おわりに
SQLFluffのルールの説明のスライドにも書いてありますが、まだまだSQLは現役バリバリだと思うので、少しでも多くの品質の高いSQLがデプロイされている分析基盤が少しでも増えればいいなと思っています。
ぜひ試してみて、導入の検討をしてみる機会になれば幸いです。
Discussion