Tracing API

[Jamie Stackhouse]

The question

Any interest in adding an official tracing mechanism to the database/sql package for Go 1.10?

Who

I will create an RFC to submit to golang/go, looking for any coordination information to help design the document.

Why?

With OpenTracing and Amazon X-Ray looking at adding official Go APIs, and all the other various vendors out there looking to add support in their own ways, to improve cohesion I was thinking that database/sql should get its own "httptrace" sub package in the form of sqltrace.

There is a demo implementation already in place for the methodology to follow with the httptrace library, and we've got context support in database/sql now that could be used for any request specific data that needs to be kept through the life-cycle of the call.

Why now?

I started to think about this because of the open source of the Amazon X-Ray SDK beta for Go. The implementation they have done is not *sql.DB compliant, they change the signatures of Exec, Query, etc to accept contexts. I created one ticket https://github.com/aws/aws-xray-sdk-go/issues/13 that is related to restoring the interface compatibility in Go 1.8+ where we have context native functions to call. Adding a sqltrace library 

Additionally, I think that adding this would prevent people from needing to change the interface to support tracing so that work proposed in https://github.com/aws/aws-xray-sdk-go/issues/8 wouldn't be necessary.

Thank you for your consideration. I will be preparing an RFC document to submit to the golang project, with proposed interfaces. Just looking for any additional coordination or assistance in considering possible issues to include as part of the proposal.

[Daniel Theophanes]

Hello, Thanks you for the detailed description,

To start off with, are you familiar with this issue: https://github.com/golang/go/issues/18080 ?

I'm slightly fuzzy one what your aim is. It looks like there are two related, but different issues.

 1. You are considering refactoring your xray.DB methods to be compatible with sql.DB. That sounds fine to me. 

 2. You are wanting to create a sqltrace package RFC. Sounds good. Please do so in context of golang/go#18080 .

--
You received this message because you are subscribed to the Google Groups "golang-sql" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-sql+...@googlegroups.com.
To post to this group, send email to golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-sql/74a2cbc5-89f4-47c4-865e-1cb07d789367%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jamie Stackhouse]

This is exactly what I was looking for. Previous work to include and shape the proposal on.

Apologies for not making this clearer!

Yes, there really are two conflated issues here as you mentioned. I only mention the first, as it was the pain point I experienced as someone who wanted to integrate the X-Ray SDK. I assumed it was built this way because of the lack of a standard way to trace SQL, as they do make use of the httptrace mechanism, and my initial research of each other tracing library also appears to do this wrapping.

Thank you for pointing me to previous works. Appreciate it.