Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable custom handling of prepared queries #2618

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant