Enable Prisma to ignore specified / only look at specified DB tables

Problem

I am developing an application that uses Prisma to facilitate DB operations with DB/tables and I am using Prisma migrations to create or alter those tables (this part works OK).

But the application also uses dynamic tables (their names and structure are not yet defined) which are not defined by Prisma schema and will not be created by Prisma migrations. For local development and testing I have created one such table in the database (SQL server).

When running prisma migrate I get an error about database drift due to the existing table that prisma doesn’t have a clue about but which I need.

Suggested solution

Add a command line parameter for prisma migrate dev to ignore specified tables.

Alternatives

Alternatively it could be configurable in Prisma schema, not sure which way is better.

Additional context

At the moment I have created a special DB user which is denied the access to the table I need to ignore. While it works it is not exactly user friendly.

---

Update: adding an example.

workaround example

For the workaround you need the new user/login, and ability to use that login just to run prisma migrate dev. Since I use SQL server I used GUI of mssms. Here I have put together some script but I am not an expert in TSQL so not sure if it does the same as what I did in the UI.

USE [master]
CREATE LOGIN [_migrator] WITH PASSWORD=N'QWERTY', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
-- dbcreator role is needed to create shadow DB
ALTER SERVER ROLE [dbcreator] ADD MEMBER [_migrator]
USE [datatools]
CREATE USER [_migrator] FOR LOGIN [_migrator]
-- db_ddladmin role alows the usr to do almost everything...
ALTER ROLE [db_ddladmin] ADD MEMBER [_migrator]
GO

-- ...except stuff bellow - DENY all operations on table [ignore_this_table]. feel free to have more tables here.
-- note that DENY ALL... seems to be deprecated but may still work and maybe not all statements are needed
-- for this task. Since I don't know any better I denied all permissions.
DENY ALTER ON [dbo].[ignore_this_table] TO [migr]
DENY CONTROL ON [dbo].[ignore_this_table] TO [_migrator]
DENY DELETE ON [dbo].[ignore_this_table] TO [_migrator]
DENY INSERT ON [dbo].[ignore_this_table] TO [_migrator]
DENY REFERENCES ON [dbo].[ignore_this_table] TO [_migrator]
DENY SELECT ON [dbo].[ignore_this_table] TO [_migrator]
DENY TAKE OWNERSHIP ON [dbo].[ignore_this_table] TO [_migrator]
DENY UPDATE ON [dbo].[ignore_this_table] TO [_migrator]
DENY VIEW CHANGE TRACKING ON [dbo].[ignore_this_table] TO [_migrator]
DENY VIEW DEFINITION ON [dbo].[ignore_this_table] TO [_migrator]
GO

Feel free to suggest improvements to above TSQL script.

Then, in the same directory with schema.prisma I have .env file

DB_HOST=localhost
DB_USER=arnold
DB_PASSWORD=QWERTY
DB_DATABASE=skynet
DATABASE_URL=sqlserver://${DB_HOST};database=${DB_DATABASE};user=${DB_USER};password=${DB_PASSWORD};trustServerCertificate=true;

That allows me to issue the following command (in bash) DB_USER=_migrator DB_PASSWORD=QWERTY bash -c 'npx prisma migrate dev'

This way, only the prisma migrate runs under the '_migrator ’ user while everything else, like running the server runs under credentials defined in .env

Not the best way of working but works for me.

[dvins]

We love Prisma and really want to like Prisma Migrate, but In lieu of some basic attributes to be able to specify tables (or views or other elements) to ignore we’re considering falling back to Knex (or another mechanism entirely) for all table schema work. There are just too many hoops to jump through when it does not have total control over the entire namespace. Unfortunately, that’s not an option for us with disparate microservices and shared query space. We’re already having hard enough time with the one Prisma schema file to rule them all.

[chaiwa-berian]

Yes, this feature would be helpful. I also want to add new tables to an already exisiting database and only want to manage/version the new tables using Prisma without affecting the rest of the tables in the database. My application will only use the new tables but other exiting applications will continue to use the existing tables and the new tables from my App.