Skip to content

Conversation

@Jille
Copy link
Contributor

@Jille Jille commented Aug 14, 2023

Without prepared queries, one can use arbitrary wrappers as a DBTX. For example to measure query timing.

With prepared queries however, only DBTX.PrepareContext() is called, which must return a *sql.Stmt. That is a concrete type and there's no easy way to create one yourself with any overrides.

Even more difficult is when in a transaction, when we call (*sql.Tx).StmtContext() which also must return a *sql.Stmt. *sql.Tx is also a concrete type here that can't be overwritten.

Because a Go interface { StmtContext(ctx, *sql.Stmt) AnotherInterface } wouldn't match *sql.Tx, we can't easily just intercept even that.

So the best way I can think of is allowing a custom interceptor which people can use to do whatever they want in their wrapping.

Without prepared queries, one can use arbitrary wrappers as a DBTX. For
example to measure query timing.

With prepared queries however, only DBTX.PrepareContext() is called,
which must return a *sql.Stmt. That is a concrete type and there's no
easy way to create one yourself with any overrides.

Even more difficult is when in a transaction, when we call
(*sql.Tx).StmtContext() which also must return a *sql.Stmt. *sql.Tx is
also a concrete type here that can't be overwritten.

Because a Go interface { StmtContext(ctx, *sql.Stmt) AnotherInterface }
wouldn't match *sql.Tx, we can't easily just intercept even that.

So the best way I can think of is allowing a custom interceptor which
people can use to do whatever they want in their wrapping.
@Jille
Copy link
Contributor Author

Jille commented Aug 14, 2023

One alternative is a config flag that simply omits (*Queries).{exec,query,queryRow}. Those have pretty much the signature of the callback we should expose. (Only difference being the query string being passed in next to the prepared statement.)

The advantage is that it is less complexity on our side. The disadvantage is that users would have to add files to the generated package to implement these private methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant