Replies: 1 comment
-
const getPreparedStatements = (db: DB) => {
const getSomething = db.query.something
.findFirst({
where: eq(something.id, sql.placeholder('id')),
})
.prepare('getSomething')
return { getSomething }
}
export class CustomerSchedulersRepository {
#db: DB
#statements: ReturnType<typeof getPreparedStatements>
constructor(db: DB) {
this.#db = db
this.#statements = getPreparedStatements(db)
}
get(id: string) {
return this.#statements.getSomething.execute({ id })
}
} here's how I tried to organise my code, I really have no idea if it's good or not 🤷♂️, but in my experience it works ok, I don't lose any type-safety anywhere, I don't find the api that awkward, having the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I want to use prepared statements in my repository class. Typically you would pass in the database object into the class and make calls there. I'm not sure whether the prepared statement should be outside of the class, or inside the class when using it in the context of aws lambas / server functions. Looking for another brain to share some thoughts...
Option 1 - Prepared statement outside the repository class
Option 2 - Prepared statement inside the repository class
My own answer: Based on the docs for prepared statements, it says if I want to reuse my db connection and prepared statements, it just has to be declared outside the handler, so in this case, I think option 1 is the correct solution right?
Next logical step...
So then if option #1 is right, the next logical step seems to be creating a class of prepared statements and a repository class to call that prepared statement class. Does this still get the benefit of prepared statements, or is this overcomplicating it?
Beta Was this translation helpful? Give feedback.
All reactions