diesel-tracing
diesel-tracing copied to clipboard
CQCL
Connection telemetry middleware for diesel and tracing
I tend to use [diesel-async](https://github.com/weiznich/diesel_async) for connections now, so it might be nice to support that. Though perhaps it ought to be a separate crate.
Both fields are just what the server is listening on, not what the client connects to. Need to find a better way of discovering this information.
I know this isn't supported as of now, but I'm curious on what the best way would be. I think a feature is probably not the way to go, but...
I've found it's quite hard to explain how this library works with just words, so some code examples would be useful.
Maybe it's more of a 'me' problem, but from [docs](https://docs.rs/diesel-tracing/latest/diesel_tracing/) there's nothing being shown as exported by the library and in the `Usage` section there's a mention to Cargo.toml but...
https://github.com/diesel-rs/diesel/commits/master/diesel/src/connection/instrumentation.rs I think using this module rather than wrapping connections could be a lot nicer, it will be a big breaking API change for this crate however.
In order to get more connection information for opentelemetry fields there are two possible approaches: 1. Use the libpg C FFI to parse the connection string 2. Implement a custom...
Rather than re-implement parsing for connection options it would be nice if we could just use their existing structure instead. Also means that we can be sure that we won't...
The instrumented connection for postgresql assumes that you are connecting over a network and cannot handle unix sockets