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.

Sign up for GitHub

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

Jump to bottom

go: expose DBTX inside Queries (via flag) #3273

Open
toqueteos opened this issue Mar 15, 2024 · 5 comments · May be fixed by #3803
Open

go: expose DBTX inside Queries (via flag) #3273

toqueteos opened this issue Mar 15, 2024 · 5 comments · May be fixed by #3803
Labels
enhancement New feature or request

Comments

@toqueteos
Copy link

toqueteos commented Mar 15, 2024 •
edited
Loading

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 to DB
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
@toqueteos toqueteos added enhancement New feature or request triage New issues that hasn't been reviewed labels Mar 15, 2024
@francesconi
Copy link

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.

func (q *Queries) Pool() *pgxpool.Pool {
	return q.db.(*pgxpool.Pool)
}

We also add receiver functions for raw queries that are currently not being able to be interpreted by sqlc.

@toqueteos
Copy link
Author

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.

func (q *Queries) Pool() *pgxpool.Pool {
	return q.db.(*pgxpool.Pool)
}

We also add receiver functions for raw queries that are currently not being able to be interpreted by sqlc.

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
Copy link

Have you also considered using emit_methods_with_db_argument?

@toqueteos
Copy link
Author

toqueteos commented Apr 4, 2024 •
edited
Loading

Have you also considered using emit_methods_with_db_argument?

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 call Exec, Query and/or QueryRow.

@kyleconroy kyleconroy removed the triage New issues that hasn't been reviewed label Aug 5, 2024
@Waishnav
Copy link

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 call Exec, Query and/or QueryRow.

@toqueteos, this is ideal way, suppose you have to work in application where database per tenant architecture is followed. suppose you are working turso, 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 with Queries

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 to Queries instance.

@kyleconroy @francesconi, Should I raise the PR for this issue by adding new configuration key for it?

@quantumsheep quantumsheep linked a pull request Jan 23, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(codegen): expose DBTX inside Queries when expose_db_connection is enabled quantumsheep/sqlc
4 participants
@kyleconroy @toqueteos @francesconi @Waishnav