-
Notifications
You must be signed in to change notification settings - Fork 231
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
feat(js-connectors): DX, enable hooks for connect()
and disconnect()
#4177
base: main
Are you sure you want to change the base?
Conversation
…s", ...) with JS connectors
…Adapter" DX proposal
CodSpeed Performance ReportMerging #4177 will not alter performanceComparing Summary
|
async disconnect() { | ||
debug('[js::disconnect]') | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One would be inclined to run await this.pool.end()
upon disconnection, releasing the connection pool resources.
This operation can only be done once per pool, or it would trigger an error. However, one can freely alternate await prisma.$connect()
with await prisma.$disconnect()
, so we can't release the pool on disconnect()
.
Would the Node.js process remain hanging due to pending database connections? No, they would be automatically released a few milliseconds after the last query execution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For that and previous comment, I think semantically correct (as in, "does what the method name suggests" thing would be creating pool in connect
each time it's called and then completely destroy it in disconnect
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or are we just adding stubs for methods and will do actual implementation later?
async connect() { | ||
debug('[js::connect]') | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One would be inclined to add await this.pool.connect()
, but that wouldn't refresh the pool connections.
Rather, it would select one to use that as a "transactional client".
@@ -99,6 +99,17 @@ pub trait Queryable: Send + Sync { | |||
fn requires_isolation_first(&self) -> bool; | |||
} | |||
|
|||
#[async_trait] | |||
pub trait Connectable: Queryable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this trait be moved to js-connectors instead? I don't think quaint's connecteors implement that, JsConnector
is the only one that needs it.
@@ -128,3 +139,5 @@ macro_rules! impl_default_TransactionCapable { | |||
} | |||
|
|||
pub(crate) use impl_default_TransactionCapable; | |||
|
|||
pub trait JsConnectorLike: TransactionCapable + Connectable {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here, this looks out of place in quaint to me.
c17a20a
to
437eef0
Compare
This PR ensures that:
QueryEngine::connect()
calls theconnect()
method on the given JS ConnectorQueryEngine::disconnect()
calls thedisconnect()
method on the given JS ConnectorThis PR is based on #4174.