Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic formatter for SQL #2356

Closed
jml opened this issue Apr 24, 2020 · 2 comments
Closed

Automatic formatter for SQL #2356

jml opened this issue Apr 24, 2020 · 2 comments

Comments

@jml
Copy link

jml commented Apr 24, 2020

Describe the feature

dbt fmt, a sub-command that automatically formats the SQL in a dbt project.

Ideally, this could be run as a pre-commit hook. It would edit files in place, operating in much the same way as black or go fmt

Describe alternatives you've considered

  • https://pypi.org/project/sqlparse/ – does a very bad job with complex queries, doesn't understand that SQL might contain Jinja2 templates. Underlying parser is somewhat dodgy.
  • Writing my own – fun but I don't have any time. Also, would have to decide between my own use case (BigQuery) vs something more general
  • Manually formatting SQL – what we're doing now. It's a pain, and it's a waste of human creativity and energy to manually correct ones colleagues about formatting in code reviews

There's a case to be made for a super general SQL-over-Jinja2 formatter, to let people choose whether they want things like upper case keywords, but I haven't met a single person who has started using an opinionated formatter like black or go fmt who hasn't been willing to sacrifice their personal preferences for never having to care about formatting ever again.

Additional context

Not database specific, but there may well be gotchas with syntax varying between databases.

Who will this benefit?

This will primarily benefit people writing transformations, as it will mean that they won't have to care about formatting.

It will secondarily benefit code reviewers, who will no longer have to check for these things, which in turn means that teams writing analytic SQL with dbt will be able to move faster.

@jml jml added enhancement New feature or request triage labels Apr 24, 2020
@drewbanin drewbanin removed the triage label Apr 27, 2020
@drewbanin
Copy link
Contributor

great idea @jml! This is something we've been mulling over in the #linters channel in dbt Slack. I love love love the idea of this, and I started a (very rough) version of this over here: https://github.com/fishtown-analytics/dbt-sql-formatter

If you're in the market for something that exists today, check out sqlfluff. This is very much on our radar too though, and we're looking forward to integrating something like this directly into dbt someday :)

@drewbanin drewbanin added discussion and removed enhancement New feature or request labels Apr 27, 2020
@alanmcruickshank
Copy link
Contributor

alanmcruickshank commented May 4, 2020

Heya guys - sqlfluff has had a ton of upgrades recently, particularly on linting and fixing code for data warehouses like snowflake and bigquery.

I expect the next release (in a few weeks) might be worth doing some basic testing with (if you want sneak peaks, feel free to check out the current master branch). I'd also love to do some work on a public api (so that you can import sqlfluff and get sensible responses) so that it could be incorporated into dbt.

If either of you have any suggestions on what you'd want to see from a public api for sqlfluff, feel free to lodge a github issue for the kind of thing you'd like to see. This is definitely on the outline roadmap for things I'd like to support before the next major release.

@dbt-labs dbt-labs locked and limited conversation to collaborators Dec 8, 2021
@jtcohen6 jtcohen6 converted this issue into discussion #4454 Dec 8, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

3 participants