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

Thank you very very much.

Tears of happiness

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

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

v0.2.2 has been released

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

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.