Driver name issue: https://golang.org/issue/12600 But I think I would prefer to solve: https://golang.org/issue/18080
Now with connectors (sql.OpenDB) drivers may not have a "name". I would love a working proposal that would take the place of ocsql, or at least provide it hooks to work without wrapping it. On Friday, September 21, 2018 at 6:32:40 AM UTC-7, Bas Van Beek wrote: > > > 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
