Sure point, I also have doubts about modifying the request on-the-fly. >From the point of "accessing an external system" it is similar and I'd even be in favour of a generic tracing/timing mechanism for *anything* that needs I/O or is otherwise subject to latency jitter.
Perhaps widening the scope is appropriate? On Mon, 2018-09-10 at 10:12 +0100, Tristan Colgate wrote: > It's worth considering that gRPC interceptors are not passive > participants in gRPC requests. They can actively modify the requests, > and responses (e.g. to enforce authentication). It's not obvious what > that would look like for SQL, or if that is even desirable. > There is a pre-existing db/sql issue to discuss tracing (which > would also facilitate metrics collection): > https://github.com/golang/go/issues/18080 > > > On Mon, 10 Sep 2018 at 09:22 Conrad Wood <c...@conradwood.net> wrote: > > On Mon, 2018-09-10 at 09:05 +0100, Tristan Colgate wrote: > > > There are two existing projects used to achieve similar goals: > > > > > > https://github.com/ExpansiveWorlds/instrumentedsql > > > https://github.com/gchaincl/sqlhooks > > > > > > native support could probably improve things a little, but this > > is a > > > very reasonable approach. > > > > tldr; It's definitely a valid approach - I still think it is > > benefitial > > to include in sql core package. > > > > In my view, there are two benefits to adding it to the main sql > > package > > compared to wrapping a driver: > > > > 1) It makes it very simple, and thus encourages, the monitoring of > > sql > > queries, which I think is a good addition to the core golang > > libraries. > > > > 2) The interceptor can be added/removed at runtime. Of course, this > > could also be done with a driver-wrapper, but not quite as > > elegantly > > and IMHO with more potential to subtle race-conditions. > > > > 3) gRPC already has such mechanism (which is very useful) and being > > in- > > line and consistent with another package, namely gRPC, makes life > > easier for golang developers.(SQL Queries to a database are in my > > view > > similar to RPC calls, since both call external systems), > > > > 4) we can encourage 3rd parties to add interceptors to their > > products. > > For example: I like to see a hook to expose metrics to prometheus. > > currently the default client exposes useful golang core metrics > > (e.g. > > "go_gc_duration_seconds"). Adding it to core language (and applying > > the > > compatibility guarantees) is likely to increase uptake and we all > > benefit. Thus I could submit a patch to prometheus and say "look, > > this > > exposes more core metrics" ;) > > > > > > > > > > > > -- > You received this message because you are subscribed to a topic in > the Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/top > ic/golang-nuts/g8rBUu9MMmw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to g > olang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
