🦔sqlfmtによって何を解決したいのか2023/05/13に公開2件SQLdbttechDiscussionぺい(pei0804)2023/05/13面白い記事ありがとうございます。 私の考えもちょっと書いてみました。 私は、sqlfluffとsqlfmt、両方を利用したことがありますが、現在では、sqlfluffをやめて、sqlfmt一本になりました。 理由は、tenajimaさんが書かれてることと同様で、sqlfmtは考えることが少ないことと、fmtだけで必要十分だったためです。 また高速に動作するため、時間の節約にもなりました。（2分30秒から3秒くらいになった） sqlfluffは、地味にdbt macroとの相性が悪く、lintを通すためのテクが要求されたり、自動で修正されないルールとかを通すための編集が、必要になることがあります。 それぞれの問題は軽微でしたが、複数人の開発となると無視できないコストでした。 sqlfmtは、当記事にも書かれてる通り、設定する余地がほとんどなく、簡単に使えます。しかも、高速です。 最初は、sqlfluffに比べて調整できないことにモヤモヤした時もありましたが、一度sqlfmtでやってみたら、これで十分じゃんってなったのもあり、sqlfmtだけで運用を今日まで続けています。 tenajima2023/05/13コメントありがとうございます！ sqlfluffは、地味にdbt macroとの相性が悪く、lintを通すためのテクが要求されたり、自動で修正されないルールとかを通すための編集が、必要になることがあります。 それぞれの問題は軽微でしたが、複数人の開発となると無視できないコストでした。 両方使ったことある意見とても貴重です、ありがとうございます。 生産性を阻害する要因の撲滅という意味ではsqlfluffが新たな阻害要因となってしまうのは本末転倒だなと感じました。sqlfluffを導入することが目的とならないよう考える必要あるなと考えさせられました。 返信を追加
ぺい(pei0804)2023/05/13面白い記事ありがとうございます。 私の考えもちょっと書いてみました。 私は、sqlfluffとsqlfmt、両方を利用したことがありますが、現在では、sqlfluffをやめて、sqlfmt一本になりました。 理由は、tenajimaさんが書かれてることと同様で、sqlfmtは考えることが少ないことと、fmtだけで必要十分だったためです。 また高速に動作するため、時間の節約にもなりました。（2分30秒から3秒くらいになった） sqlfluffは、地味にdbt macroとの相性が悪く、lintを通すためのテクが要求されたり、自動で修正されないルールとかを通すための編集が、必要になることがあります。 それぞれの問題は軽微でしたが、複数人の開発となると無視できないコストでした。 sqlfmtは、当記事にも書かれてる通り、設定する余地がほとんどなく、簡単に使えます。しかも、高速です。 最初は、sqlfluffに比べて調整できないことにモヤモヤした時もありましたが、一度sqlfmtでやってみたら、これで十分じゃんってなったのもあり、sqlfmtだけで運用を今日まで続けています。 tenajima2023/05/13コメントありがとうございます！ sqlfluffは、地味にdbt macroとの相性が悪く、lintを通すためのテクが要求されたり、自動で修正されないルールとかを通すための編集が、必要になることがあります。 それぞれの問題は軽微でしたが、複数人の開発となると無視できないコストでした。 両方使ったことある意見とても貴重です、ありがとうございます。 生産性を阻害する要因の撲滅という意味ではsqlfluffが新たな阻害要因となってしまうのは本末転倒だなと感じました。sqlfluffを導入することが目的とならないよう考える必要あるなと考えさせられました。 返信を追加
tenajima2023/05/13コメントありがとうございます！ sqlfluffは、地味にdbt macroとの相性が悪く、lintを通すためのテクが要求されたり、自動で修正されないルールとかを通すための編集が、必要になることがあります。 それぞれの問題は軽微でしたが、複数人の開発となると無視できないコストでした。 両方使ったことある意見とても貴重です、ありがとうございます。 生産性を阻害する要因の撲滅という意味ではsqlfluffが新たな阻害要因となってしまうのは本末転倒だなと感じました。sqlfluffを導入することが目的とならないよう考える必要あるなと考えさせられました。
Discussion
面白い記事ありがとうございます。
私の考えもちょっと書いてみました。
私は、sqlfluffとsqlfmt、両方を利用したことがありますが、現在では、sqlfluffをやめて、sqlfmt一本になりました。
理由は、tenajimaさんが書かれてることと同様で、sqlfmtは考えることが少ないことと、fmtだけで必要十分だったためです。
また高速に動作するため、時間の節約にもなりました。（2分30秒から3秒くらいになった）
sqlfluffは、地味にdbt macroとの相性が悪く、lintを通すためのテクが要求されたり、自動で修正されないルールとかを通すための編集が、必要になることがあります。
それぞれの問題は軽微でしたが、複数人の開発となると無視できないコストでした。
sqlfmtは、当記事にも書かれてる通り、設定する余地がほとんどなく、簡単に使えます。しかも、高速です。
最初は、sqlfluffに比べて調整できないことにモヤモヤした時もありましたが、一度sqlfmtでやってみたら、これで十分じゃんってなったのもあり、sqlfmtだけで運用を今日まで続けています。
コメントありがとうございます！
両方使ったことある意見とても貴重です、ありがとうございます。
生産性を阻害する要因の撲滅という意味ではsqlfluffが新たな阻害要因となってしまうのは本末転倒だなと感じました。sqlfluffを導入することが目的とならないよう考える必要あるなと考えさせられました。