Did you know it’s impossible to set a statement timeout for your DB connections in prisma? There’s no hook to run commands when a connection in a pool is established, and there’s no exposed setting for it. The only way to manage it is either to set it at the user level or to set up whatever they call a middleware layer (client extension?) that issues the command to set the timeout before every single query

An engine that doesn’t allow you to set per-connection settings effectively is pretty crazy IMO.

It's possible now with the built-in "db adapter" plugin. I also have lots of misgivings about the Prisma ORM, but this particular thing is possible now.

Can’t find any docs on this, could you point me to what you’re referencing?

Configure Prisma with https://www.prisma.io/docs/orm/overview/databases/postgresql...

Then you can pass `statement_timeout` when you create the `pg.Pool`

Oh I see, thanks! So you just need to opt out of their drivers entirely and configure with the alternative package’s driver.

One of the biggest thing that surprised me is that there's a binary written in Rust that listens for your queries and then passes them to the underlying database.

That's unnecessary moving part IMHO. Is it still the case or they changed their architecture recently?

It's still there, albeit not for long.

There were ample reasons in the past whereby going down this path made architectural sense. The primary one being multi-language support. Since then, TS and JS have found their way to the top of "the programming langs of choice" charts and so we're digging into removing the Rust based components and making them optional.

We'll share more on this in the coming weeks.

That's great news. The rust client has eaten a few days of my and my co-workers' life by causing deployment issues

How would that affect the now unofficial Go client?

Great point! We'll be taking all of that into account. The idea is not to make this a breaking change as a lot of community work went into the various lang support modules that are available.

Partly this is what makes this a fun and interesting challenge that goes beyond just the tech and the team is eager to get their hands dirty to solve this. For now, lots of ideas on the board. Once we have a plan, we will start to share in order to get community feedback.

The challenge, as we see it, is not that we didn't address open issues (we've put out a release every 3 weeks for the past 4+ years!), the challenge instead is that we didn't explain how we pick the issues that we do to work on. That is being addressed and you'll soon see us share our process transparently.

With close to 400K monthly active developers using our library and over 9M monthly downloads on NPM, one can imagine that the issues keep piling up!

From an outside perspective it seems like issues are prioritized based on how easy they are to fix.

To be fair this kind of makes sense, especially when the thing that makes many tasks difficult is finding solutions that don't break existing usage.

Yep, I can totally see how that may come across. Hopefully, once we publish our process, all of this becomes clear and the community can be part of the selection process itself.

One constant problem I run into is that Prisma does not return the IDs not the full rows when doing a batch insert. It only returns the counts.

Honestly, I hated Prisma for a while. I've tried to actively rip it out of multiple projects. But, typed queries + views being supported have rally started to change my mind. Prisma is great for basic CRUD operations, and those two features give me a really solid, type safe escape hatch for most of my complaints.

Dropping the rust client will solve another big complaint. I definitely feel the issues languishing problem. I've submitted a few confirmed reproducible bugs that have hung out for a couple years. Still, I'm happier with their recent direction than I would have expected.