Open
Description
What do you want to change?
Currently the autogenerated db.go
file contains this two types:
type DBTX interface {
Exec(context.Context, string, ...interface{}) (pgconn.CommandTag, error)
Query(context.Context, string, ...interface{}) (pgx.Rows, error)
QueryRow(context.Context, string, ...interface{}) pgx.Row
}
// [..]
type Queries struct {
db DBTX
}
Sometimes, because of ✨ questionable business reasons ✨ we would like to use the DBTX
inside a *Queries
to write some raw SQL but currently that's not possible.
An escape hatch behind a flag, something like emit_public_dbtx
, to allow this would be very welcome.
Options for the changes required:
- A) Embed DBTX inside Queries
type Queries struct {
DBTX
}
- B) Make
db
public by renaming it toDB
type Queries struct {
DB DBTX
}
- C) Add a new method to Queries which exposes the DBTX (this option requires the least changes)
// There might be better names than Conn, I'm open to suggestions
func (q *Queries) Conn() DBTX {
return q.db
}
What database engines need to be changed?
None
What programming language backends need to be changed?
Go
Activity
francesconi commentedon Apr 4, 2024
Why don't you add a receiver function in a new file inside the generated package? We do something similar when we have to deal with transactions outside the generated package.
We also add receiver functions for raw queries that are currently not being able to be interpreted by sqlc.
toqueteos commentedon Apr 4, 2024
That's my current workaround, at the cost of sqlc's "out" folder no longer being 100% autogenerated thus it can't be blindly deleted anymore.
francesconi commentedon Apr 4, 2024
Have you also considered using
emit_methods_with_db_argument
?toqueteos commentedon Apr 4, 2024
I don't think so, I'll give it a try this afternoon.
EDIT: Tried, that flag does "the opposite" of what I want. It requires a
DBTX
on every query.I just need the underlying
DBTX
to be accessible so I can callExec
,Query
and/orQueryRow
.Waishnav commentedon Oct 29, 2024
@toqueteos, this is ideal way, suppose you have to work in application where
database per tenant
architecture is followed. suppose you are workingturso
, in such case, you have to find the pool connection according to the user and attach it to queries in runtime, instead of being tightly coupled withQueries
Even though, in certain edge case like you are facing, there is need for making this
DBTX
instance public, I agree that there should be configuration to have this option where we can make the db connection pool as public struct attached toQueries
instance.@kyleconroy @francesconi, Should I raise the PR for this issue by adding new configuration key for it?
expose_db_connection
is enabled #3803