Hello all--I just came across something a bit annoying. Looks like Prisma 2 is trying to be "smart" by checking constraints that are implied by its known foreign key settings. I'm simply doing:

await prisma.myTable.deleteMany();

...and I'm getting an error from Prisma. When I replace it with

await prisma.$executeRaw(`DELETE FROM "myTable";`);

It works fine. I'm using PostgreSQL. I really want to rely on Postgres to enforce any constraints, if only because, well, Postgres is going to do the foreign key constraint check anyway, and therefore whatever query Prisma is performing to verify the constraint is 100% wasted time. This particular situation is easily worked around (and it's mostly irrelevant anyway, since it's part of the debug DB seed code); what worries me is any more "trying to be smart" queries Prisma might be doing every time any change is made to the data that mean we get 2-3x as many DB calls as actually required for an operation. (As to why I was getting a bogus error: I'm using the "hacked"

@view

approach to expose a

MATERIALIZED VIEW

to Prisma. I don't actually care that the mapping isn't perfect, so it's not really relevant, unless somehow the

@view

approach is causing the extra query above.)

@Tim Mensch 👋 This is due to an issue with cascade deletes and should be configurable in the release that we will be doing today. You can read more about that here: https://www.notion.so/prismaio/Fine-grained-control-for-referential-actions-ON-DELETE-ON-UPDATE-6a2f9b8550204992ba08ff7351c9afae https://github.com/prisma/prisma/issues/2810

... which was actually released as a preview feature behind a preview feature flag today!

@Ryan @janpio Hmm...so since this is a "fake" relationship, what would I tell it? Just that it's ON DELETE CASCADE, so that Prisma thinks it will automatically delete the referenced table? And it would be crucial that Prisma knows that it's really automatic and completely handled by Postgres. It's a Postgres error to try to delete from the

MATERIALIZED VIEW

, so that wouldn't exactly go over well. But again: I'm asking about the general case. Can I tell Prisma to just never do the foreign key check? On any table ever? Because this is one place that any attempt to have JavaScript/TypeScript do the work of Postgres is strictly slowing things down and providing no value.

Yes, with the preview feature flag activated in 2.26.0 there is no more code trying to emulate referential actions. It deletes what you tell it to deleted, and it will let the database do the rest.

Yes, thank you!

Word of caution though: It is a preview feature, for the reason that it might be broken in the extreme case. So test in dev, not production 😄

This project is nowhere near production (months away at least), so that's easy. 🙂