Because we don't want it to proliferate through your entire code base and packages as sql.DB is a struct, not an interface. It needs to be completely invisible to your code base once set-up.
On Friday, September 21, 2018 at 5:32:24 PM UTC+2, Tamás Gulácsi wrote: > Why do you want to wrap the driver? Why not just the db? > > 2018. szeptember 21., péntek 15:32:40 UTC+2 időpontban Bas Van Beek a > következőt írta: >> >> >> 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.
