Skip to content
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

Pretty SQL before sending to execution engine #2935

Open
MikeWallis42 opened this issue Jul 24, 2024 · 9 comments
Open

Pretty SQL before sending to execution engine #2935

MikeWallis42 opened this issue Jul 24, 2024 · 9 comments
Labels
Improvement Improves existing functionality

Comments

@MikeWallis42
Copy link

A small request I hope.
Would it be possible to use SQLGlot's pretty functionality before executing SQL statements?
It would be much easier to find syntax issues if it wasn't one long line.

@eakmanrq eakmanrq added the Improvement Improves existing functionality label Jul 24, 2024
@patricksurry
Copy link

had a similar comment for audits - it's great to be able to cut & paste sql for a failing audit, but would be even better if I could see pretty sql without an external tool. either by default or with sqlmesh audit --pretty or something.

@MikeWallis42
Copy link
Author

@izeigerman, please correct me if I'm wrong but would this be as simple to implement as changing this line from False to True?

https://github.com/TobikoData/sqlmesh/blob/v0.117.0/sqlmesh/core/engine_adapter/base.py#L2037

If so then I'd be happy to contribute this.

@izeigerman
Copy link
Member

@MikeWallis42 is the purpose of this to make the queries in logs prettier? Or some other place?

@izeigerman
Copy link
Member

I'm concerned that this will significantly increase the size of the payload and the IO overhead as a result. I'm open to making this configurable with this behavior being disabled by default.

@MikeWallis42
Copy link
Author

If I were to be really specific then this would be to better enable debugging and would typically be used during development more than in a production setting.
As SQLGlot cannot and should not be validating the syntax of the SQL (apart from really basic things), it's often the case that bad SQL is written and run whilst developing.
Finding the location of the bad SQL (from the execution engine) is typically easier when we can scan down and then across.
At the moment all the issues are on line 1 and, sometimes, several thousand characters in.

It might be that this would be configured against a specific gateway in the context of SQLMesh, at least in the way that I'm using it currently.

@tobymao
Copy link
Contributor

tobymao commented Aug 22, 2024

@MikeWallis42 are you planning to make a PR?

@MikeWallis42
Copy link
Author

I would love to have a go! I've made a start today

@tobymao
Copy link
Contributor

tobymao commented Aug 23, 2024

Great let us know if you need any help, you can ping us on slack.

@sungchun12
Copy link
Contributor

@MikeWallis42 looks like you're not the only one that cares about this: #3086 (comment)

But looks like you don't want to see the pretty SQL rendered in the terminal, only in the query history for the engine executing the SQL. Is that correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Improves existing functionality
Projects
None yet
Development

No branches or pull requests

6 participants