Replies: 1 comment 4 replies
-
We should keep the name that is in the dependencies because
So now it will be mandatory? However, it can be hard to realize later that I need to add the driver to unlock specific config for the driver/vendor I use, so, if it is mandatory, better to be explicit.
There is a case I know that would instantly fail: PGLite (With Maintaining a list of cross-dialect compatibilities may be risky and time-consuming? I would be strict: faster to implement, better configuration (what I set is what I use). |
Beta Was this translation helpful? Give feedback.
-
Drizzle ORM is designed to be dialect specific and used with a particular range of database drivers per dialect. While it lets Drizzle move fast and rapidly add support for whatever new dialects/drivers/databases emerged on the market, it makes it harder for newcomers to onboard.
As of now we're going through a major release of Drizzle Kit and adding support for mostly all drivers available, we decided to sit and talk through how we can make it better.
as of now developers need to specify both
dialect
anddriver
in the config file. Dialect being either ofpg | mysql | sqlite
and this list will be joined bymariadb | cockroachdb | mssql | turso(libsql)
and on the other hand we have drivers likenode-pg | postgresjs | neon-serverless | aws-data-api-pg | xataio
and that's only for postgres dialect.Drizzle config is meant to be typed and
driver
param presence infersdbCredentials
object so that you can enjoy typed params experience. While we already have a variety of different drivers, their naming brings even more confusion and you end up with something like this:in that case
driver: "pg"
is anode-postgres
driver which is namedpg
on the npmwe also have
postgresjs
driver which is namedpostgres
on the npm, which will lead to:and it brings confusion, cause you as a developer install
npm i pg
but in our config it will be callednode-pg
which is how the library is called, or driver will be calledpg
and thus another confusion of why do you have to statedialect: pg
anddriver: pg
. Goes the same withpostgresjs
driver which is going to be eitherdialect: pg
anddriver: postgres
ordriver: postgresjs
.We're aiming move away from the model of
developer passing a driver instance to Drizzle constructor
to the knex-like one, to reduce the initial learning curve/complexity for developers to jump into Drizzle:Taking in count all the above we've came up with potential solution for the config file to unify
driver
anddialect
fields into one, which will consist ofdialect:driver
and changepg
dialect topostgresql
:That would let us keep
dbCredentials
typed and will end up in a list ofdatabase
params beBig questions:
push
,pull
andstudio
commands, since those only requiredialect
.postgres:neon
for example, he might be able to connect to neon database not through@neondatabase/serverless
driver, but throughpg
orpostgres
drivers. Should we check runtime deps strictly for@neondatabase/serverless
and fail if it's not present or also try bothpg
andpostgres
For the first one we might let them just provide
database: "dialect"
without:driver
part?For the second one we lean heavily towards trying all possible drivers and connect through the first one available as long as all of them compatible
UPD(27 may 2024)
better-sqlite
andlibsql
compatibility - we need to automatically prefix files url withfile:
forlibsql
if missing and make sure to trim it forbetter-sqlite
forneon
andvercel
serverless drivers we need to check for-pooler
in connection strings and automatically create aPool
instead of aClient
to not throw errors@neondatabase/serverless
usecreatePool
@vercel/postgres
usecreatePool
(waiting for Vercel to resolve-pooler
issue, which prevents pool creation with a non-pooler connection)Beta Was this translation helpful? Give feedback.
All reactions