The preferred method of working with database/sql is to use registered driver names to identify which driver to use for connecting to the database.
OpenCensus <https://opencensus.io> now has instrumentation for database/sql by allowing database drivers to be wrapped with the ocsql <https://github.com/opencensus-integrations/ocsql> package. The most idiomatic way to set-up ocsql <https://github.com/opencensus-integrations/ocsql> is to do something like this: import ( _ "github.com/mattn/go-sqlite3" "github.com/opencensus-integrations/ocsql" ) var ( driverName string err error db *sql.DB ) // Register our ocsql wrapper for the provided SQLite3 driver. driverName, err = ocsql.Register("sqlite3", ocsql.WithAllTraceOptions()) if err != nil { log.Fatalf("unable to register our ocsql driver: %v\n", err) } // Connect to a SQLite3 database using the ocsql driver wrapper. db, err = sql.Open(driverName, "resource.db") Unfortunately database/sql does not have a function to retrieve the registered driver.Driver by its driver name, which could look like this: // DriverByName showsn an example of a function to retrieve a registered driver by its name. func DriverByName(name string) driver.Driver { driversMu.Lock() defer driversMu.Unlock() return drivers[name] } So underwater ocsql <https://github.com/opencensus-integrations/ocsql> does the following dirty trick to retrieve the driver.Driver: func Register(driverName string, options ...TraceOption) (string, error) { // retrieve the driver implementation we need to wrap with instrumentation db, err := sql.Open(driverName, "") if err != nil { return "", err } dri := db.Driver() if err = db.Close(); err != nil { return "", err } ... } The problem however is that Go 1.10 introduced the new interface DriverContext which, if implemented by a database driver, will make the call to sql.Open to retrieve the driver.Driver fail as it can error on the call to OpenConnector: // If a Driver implements DriverContext, then sql.DB will call // OpenConnector to obtain a Connector and then invoke // that Connector's Conn method to obtain each needed connection, // instead of invoking the Driver's Open method for each connection. // The two-step sequence allows drivers to parse the name just once // and also provides access to per-Conn contexts. type DriverContext interface { // OpenConnector must parse the name in the same format that Driver.Open // parses the name parameter. OpenConnector(name string) (Connector, error) } If the database driver to wrap with ocsql also does not export its driver.Driver implementation it will be not possible to use ocsql. Would like to hear from the Go team and community if adding a DriverByName type function is acceptable given the use case presented above. It would surely make ocsql less brittle and better supported. Cheers, Bas van Beek -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
