Ecto.DevLogger - an alternative logger of SQL queries in development

Ecto.DevLogger is an alternative logger of SQL queries in development

It inlines bindings into the query, so it is easy to copy-paste logged SQL and run it in any IDE for debugging without manual transformation of common elixir terms to string representation (binary UUID, DateTime, Decimal, json, etc). Also, it highlights db time to make slow queries noticeable. Source table and inlined bindings are highlighted as well.

Links

58 Likes

You’ve pumped my developer happiness to 1_000 today! :yellow_heart:

Thank you very very much.

2 Likes

Tears of happiness :+1:

1 Like

Oooh, I’ve wanted nice UUID logging for quite a while! Great job!

1 Like

Released v0.2.0 which now supports :stacktrace option, which was introduced in Ecto 3.8.0 :tada:.
Screenshot in the first post was updated.

v0.2.2 has been released :tada:

The fixes are small, but I’d recommend updating to the latest version.

2 Likes

Thank you for this! Should be the default behavior IMO.

Thanks for this library! I have two suggestions: one being a way to exclude queries from certain sources (eg. oban_jobs) and the other is support for other types such as ULID. Happy to submit PRs if you’re interested.

Being able to copy the queries (UUID casting) would be extremely nice in the default logger.

Maybe a proposal can be made at the Ecto GitHub or mailinglist to merge both Loggers capabilities?

I don’t believe the way it’s being done in this library will be accepted into Ecto:

with <<_::128>> <- binding,
           {:ok, string} <- Ecto.UUID.load(binding) do
  1. Something matching <<_::128>> doesn’t have to be a UUID
  2. By the time Ecto gets to the logger, the string version of the UUID has been converted to binary. It’s not very desirable to convert it back to string just for logging. Keeping both versions around until logging is being explored but it’s not too simple given the number of different ways queries can be generated in Ecto and the number of different ways those queries aggregate their parameters.

It depends on what exactly should be by default. If you’re talking about inlining parameters, then that’s not an easy task.
Ecto.DevLogger doesn’t cover all the cases. It simply assumes what is the type on postgres level by elixir type. And this match is not one-to-one.
When the argument is map, we assume that json is used even though it could be hstore. When the argument is list, then we assume that it has a structure {:array, any}. However, list can be stored as json as well. The same story is for integers, floats, booleans, strings.

1 Like

Ignoring certain sources is a good feature, but if you just want to ignore oban_jobs, then it is not enough, as Oban also produces logs without source. And the issue is already solved, see Noisy with Oban · Issue #6 · fuelen/ecto_dev_logger · GitHub Probably you have to use Oban from main.
Happy to discuss solution for ULID.

There is an open PR on GitHub related to the issue

1 Like

v0.4.0 has been released :tada:

Now, we support multiple repos and Ecto.Adapters.MyXQL adapter.

3 Likes

This is friggin AMAZING!!!

I use datagrip and hate all the editing to test a logged query.

thanks for this awesome lib, should be default tbh

This has been added to Ecto.

  • [Ecto.Repo] Log human-readable UUIDs by using pre-dumped query parameters

Still eager to give this lib a try. Good work!

3 Likes

v0.7.0 has been released :tada:

I didn’t write here about previous tiny releases, but this one is notable by adding a Ecto.DevLogger.PrintableParameter protocol which allows printing yet not supported types and even user-defined postgrex types.

Also, it contains various small fixes.

1 Like