Store user-defined data in Rows, Stmt and Tx objects

[fho]

Hello,

I'm implementing an interceptor with sqlmw that records traces for database operations (instrumentedsql->sqlmw->tracing with sqlmw :-)).

When a Rows, Stmt or Tx object is created I create a parent tracing span. Operations on the Rows, Stmt and Tx structs should be created as child spans. When the Rows, Stmt, Tx operations is finished (Close(), Commit(), Rollback(), etc), the parent span is also finished.

To be able to create a child span, the parent span must be available in the methods of the Rows, Stmt and Tx objects. One way to to achieve this would be to wrap the Rows, Stmt and Tx objects again in my interceptor implementation and store the additional information in the struct.

I would like to avoid having to wrap those structs again in my interceptor. Wrapping it also requires to implement the fallback logic for the Stmt.QueryContext() and Stmt.ExecContext() methods to their non context aware variants again. This means maintaining another copy of namedValueToValue.

It would be great if sqlmw would support the usecase to store user-defined data when creating Rows, Stmt and Tx structs and access it in their methods instead. sqlmw is doing something similiar already. When for example QueryContext() is called, it stores the cx in the wrappedRows objects and passes it as parameters to methods like RowsNext() as argument, which do not have a ctx argument in the stdlib implementation.

What do you think about the idea? Does somebody have an suggestion for how to implement it? (I'll extend this issue or create a PR, when I have an idea.)

[inconshreveable]

The stated goal of the proposal seems reasonable to me. I'm afraid I don't have the time or the context in my head to evaluate the proposed solution though, although it principle it sounds like a reasonable approach.

[fho]

ok, thanks for the fast response nonetheless. Maybe something else sees it and has an opinion or even a better idea.

I experimented a bit more in the meantime: The Rows and Tx objects currently can be simply wrapped by the middleware and the parent Rows, Tx embedded. In the related interceptor methods (RowsNext, RowsClose, TxCommit, etc), a type check can be done if the passed rows or Tx is the own wrapped type. This works fine and the wrapping overhead is also negligible.

For statements the approach does not work. sqlmw wraps the driver.Stmt that is returned by the interceptors ConnPrepareContext method again into a sqlmw.wrappedStmt. Because that type is private the user can not convert it to it's own wrapped stmt type in the middleware anymore. Another difficulty with Stmts is that ConnPrepareContext returns a driver.Stmt interface. The interceptor methods operating on more specific interfaces like driver.QueryerContext, driver.ExecerContext. To be able to handle that, the user has to check in ConnPrepareContext which interfaces the passed driver.ConnPrepareContext actually implement and then wraps it in objects that have the same interfaces. Currently there are 3 interfaces that extends the Stmt in the stdlib, all combinations of those must be handled. Alternatively the same then sqlmw.WrappedParentStatement must be implemented in the middleware again.

Possible Solutions:

• make sqlmw.WrappedParentStmt public and change the parameter type of stmt in StmtQueryContext and StmtExecContext to sqlmw.WrappedParentStmt. A middleware can then extract it's own wrapped statement. This would be a simple change in sqlmw, the user would still have to cope with all the different Stmt interfaces though.
  (Independent of this issue I think this change would still make sense to clarify the interface. Currently it is hidden, that the statement interceptor methods do not get passed the same stmt that the user returned in PrepareStatement.)
• Support to store user-defined data in Stmts, Tx, Rows in the following way: A type UserData struct { atomic.Value } is introduced. Interceptor methods that return Rows, Tx and Stmts are changed to have an additional *UserData parameter. In the interceptor methods Userdata.Store() can be called to store custom data for Rows, Tx or Stmts. sqlmw stores the UserData in the wrapped Rows, Tx, Stmts. The data can be in RowsNext(), StmtQueryContext(), TxCommit(), etc retrieved via helper functions like: func GetUserDataRows(driver.Row) interface{} {}, func GetUserDataStmts(driver.Stmt) interface{} {}, func GetUserDataTx(driver.Tx) interface{} {}.