Closed zachallaun closed 1 year ago
Hi @zachallaun
Falling back to String.Chars
is not durable, as output format may differ from what is OK for DB.
%Postgrex.INET{}
is not a custom postgrex type, it is built-in, so we should have a solution for this inside the library (PR is welcome!). Users shouldn't define implementation for common structs.
Here is a comment to the related topic: https://github.com/fuelen/ecto_dev_logger/pull/7#issuecomment-1107472681
Having a custom protocol is a plan for the future as it allows usage of custom postgrex types, but I don't want to implement it now, as personally I don't use such types, not sure if there are other users, and I'm not sure about good protocol interface for now.
Hey @zachallaun
I've added support for INET and MACADDR types. Could you check main
if it works for you?
https://github.com/fuelen/ecto_dev_logger/commit/bef1be8b3cb2a91a4b8b04bd3c1ef466caed2d09
Thanks! Will give it a try tomorrow and get back to you.
Sorry for the delay; works great!
Thanks. Published a new release with these changes.
Hi there!
I just tried to give this a go and unfortunately ran into an immediate snag:
I'm using a custom type that wraps
%Postgrex.INET{}
, which is the struct thatPostgrex
returns when using theinet
underlying database type in Postgres.It seems that
stringify_ecto_params/2
doesn't have a fallback for dealing with structs that it doesn't already know about, hence the function clause error. A fallback that simply usesto_string
would be neat, since someone could then implementString.Chars
for their struct if they wished in order to format things.