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

Format SQL queries when printing them to the logs #268

Merged
merged 1 commit into from Apr 19, 2020

Conversation

shssoichiro
Copy link
Contributor

Before, the query would be formatted equivalent to the input string:

[2020-04-18T23:47:32Z DEBUG sqlx_core::postgres::executor] SELECT id, queue, ..., elapsed: 2.320µs

        SELECT id, queue, payload, status, priority, created_at, updated_at
    FROM jobs
    WHERE status = $1
    ORDER BY priority ASC, created_at ASC

After, the query is formatted cleanly and consistently:

[2020-04-19T00:30:18Z DEBUG sqlx_core::postgres::executor] SELECT id, queue, ..., elapsed: 2.280µs

    SELECT
      id,
      queue,
      payload,
      status,
      priority,
      created_at,
      updated_at
    FROM
      jobs
    WHERE
      status = $1
    ORDER BY
      priority ASC,
      created_at ASC

This uses the sqlformat crate, which was ported from the Javascript sql-formatter-plus library specifically for this purpose.

Before, the query would be formatted equivalent to the input string:

```
[2020-04-18T23:47:32Z DEBUG sqlx_core::postgres::executor] SELECT id, queue, ..., elapsed: 2.320µs

        SELECT id, queue, payload, status, priority, created_at, updated_at
    FROM jobs
    WHERE status = $1
    ORDER BY priority ASC, created_at ASC

```

After, the query is formatted cleanly and consistently:

```
[2020-04-19T00:30:18Z DEBUG sqlx_core::postgres::executor] SELECT id, queue, ..., elapsed: 2.280µs

    SELECT
      id,
      queue,
      payload,
      status,
      priority,
      created_at,
      updated_at
    FROM
      jobs
    WHERE
      status = $1
    ORDER BY
      priority ASC,
      created_at ASC

```

This uses the `sqlformat` crate, which was ported from the
Javascript `sql-formatter-plus` library specifically for this purpose.
@mehcode
Copy link
Member

mehcode commented Apr 19, 2020

Awesome.

Do you know if there is a way to emit a log as "sqlx::query" so it's easier for people to turn on/off these logs?

E.g.,

[2020-04-18T23:47:32Z DEBUG sqlx::query] SELECT id, queue, ..., elapsed: 2.320µs

@mehcode
Copy link
Member

mehcode commented Apr 19, 2020

Also it looks like your idea is to interpolate the query with the provided values. I can get behind that. Perhaps we should use some kind of coloring (maybe cyan) for the bind arguments so they stand out in the query string.

@mehcode mehcode merged commit f73149a into launchbadge:master Apr 19, 2020
@shssoichiro
Copy link
Contributor Author

The interpolation was part of the port from the Javascript library. I'm not strongly in favor of one approach or the other on that, although we have the option of using it. If we do interpolate, I agree coloring the arguments is a good idea.

As far as sqlx_core::postgres::executor changing to sqlx::query, I can look into this. I know this is set by the log crate based on the module where the log line is located. Maybe there's a way to override it, I'll have a look at the log documentation. (Alternatively there may be some way to change it by moving code around.)

@shssoichiro shssoichiro deleted the format-sql-logs branch April 19, 2020 23:34
shssoichiro added a commit to shssoichiro/sqlx that referenced this pull request Apr 20, 2020
This will make logged queries show
as from `sqlx::query` instead of `sqlx::db_name::executor`.

Followup to launchbadge#268
abonander pushed a commit that referenced this pull request Apr 23, 2020
This will make logged queries show
as from `sqlx::query` instead of `sqlx::db_name::executor`.

Followup to #268
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants