I propose that this package defines it's own Queryable rather than using pg built-ins:
|
export type Queryable = pg.ClientBase | pg.Pool; |
The advantage of this could potentially open up uses with other compatible packages or even developing adapter for other packages.
If this was possible, I could implement this narrow interface on my own, for example to implement better retry logic.
// pseudo-code
class PoolWithRetry implements Queryable {
connect(): Promise<any> {
// own implementation
}
query(): Promise<any> {
// own implementation
}
}
As a minimum, we could even just narrow the type by using Pick. But ideally, it should be more tightly defined, and only define the parts that zapatos needs.
diff --git a/src/db/core.ts b/src/db/core.ts
index d0f0271..f57b08a 100644
--- a/src/db/core.ts
+++ b/src/db/core.ts
@@ -203,8 +203,7 @@ export type GenericSQLExpression = SQLFragment<any, any> | Parameter | DefaultTy
export type SQLExpression = Table | ColumnNames<Updatable | (keyof Updatable)[]> | ColumnValues<Updatable | any[]> | Whereable | Column | ParentColumn | GenericSQLExpression;
export type SQL = SQLExpression | SQLExpression[];
-export type Queryable = pg.ClientBase | pg.Pool;
-
+export interface Queryable extends Pick<pg.ClientBase | pg.Pool, 'connect' | 'query'> { };
// === SQL tagged template strings ===
Additionally, this type of queryable detection will need a rework:
|
if (queryable instanceof pg.Pool) return 'pool'; |
|
if (queryable instanceof pg.Client) return 'client'; |
|
if (pg.native !== null && queryable instanceof pg.native.Pool) return 'pool'; |
|
if (pg.native !== null && queryable instanceof pg.native.Client) return 'client'; |
Related: #77
I propose that this package defines it's own
Queryablerather than usingpgbuilt-ins:zapatos/src/db/core.ts
Line 206 in 157da6a
The advantage of this could potentially open up uses with other compatible packages or even developing adapter for other packages.
If this was possible, I could implement this narrow interface on my own, for example to implement better retry logic.
As a minimum, we could even just narrow the type by using
Pick. But ideally, it should be more tightly defined, and only define the parts that zapatos needs.Additionally, this type of queryable detection will need a rework:
zapatos/src/db/transaction.ts
Lines 54 to 57 in 157da6a
Related: #77