Unified Drizzle driver #3097
Replies: 3 comments 1 reply
-
If you can make sure It's essential for using Managed Identity and other access token based auth to the DB. |
Beta Was this translation helpful? Give feedback.
-
What would be the current best practice for initialization logic like this one? import 'dotenv/config';
import { drizzle } from 'drizzle-orm/connect';
import { seed } from './seed';
const driver =
process.env.NODE_ENV === 'production' ? 'neon-http' : 'node-postgres';
async function main() {
const db = await drizzle(driver, process.env.POSTGRES_URL!);
await seed(db);
}
main(); |
Beta Was this translation helpful? Give feedback.
-
Is there any way to close a db connection with this new api? Previously, as instructed in discussion #228 (comment), we used the driver to close the connection, but now the driver is abstracted away into drizzle. |
Beta Was this translation helpful? Give feedback.
-
To run queries on your database Drizzle uses database drivers like
node-postgres
orpostgresjs
. It requires you to import and initialise driver and then pass to drizzle init funciton:the problem with the above is also
esm
andcjs
, if you'd be usingnode-postgres
inesm
, you'd have to:otherwise it would break and while it's technically not Drizzle - this degrades the overall DX
Our initial intention with
unified driver
was to have a prettier, more concise API and to reduce entrance friction for newcomers who are not very familiar with what database drivers are.You'd be able to just:
we've implemented this API in our recent release and it turned out this API is doomed
Because of the underlying implementation with dynamic imports - init method had to be promisified, which is a decent downgrade, yet we thought it'd be ok with all the benefits we'd have. It had to live in
/connect
module, since it turns out otherwise it will break the ability to use Drizzle in NextJS project because webpack tries to bundle all dynamic./..
imports into the bundle and our dynamic imports inconnect
module are referencing database driver libraries. Later we've found out that our current implementation of monodriver is completely unbundable unless you will explicitly tell bundler all the database drivers to be external dependencies except the one you needwhile api looks great - it is obvious now we will have to get rid of it, otherwise it will degrade DX and it will be a massive maintenance burden
We decided to not throw everything away and came up with a compromised idea to boost our original API taking in count all the experience we've gained with monodriver:
was:
now:
in order to not introduce breaking change - we will still leave support for deprecated API until V1 release. It will degrade autocomplete performance in connection params due to
DatabaseDriver | ConnectionParams
types collision, but that's a decent compromise against breaking changesThis way we can also eliminate problems like one mentioned above, when we're now creating driver for the user and since we bundle ORM both for
cjs
andesm
.Beta Was this translation helpful? Give feedback.
All reactions