Unable to run db push because of introspected inconsistencies with supabase
Hi, I'm working with a postgres database on supabase. After running db pull with a multischema setup (public+auth), I ultimately reverted back to a simple
public
access and removed all the introspected tables from my schema.prisma
. Currently my schema contains a single table unrelated to supabase. I'm trying to db push
it but I get an error as follows:
The mentioned tables (auth.users & public.profiles
) are not anymore in the schema I'm trying to push. They do still exist in the database. This is what my bare-bone schema looks like.
Is Prisma keeping track of previous introspections? I'd like prisma to completely forget about any previous connections, if thats the problem. There is no migration files either.5 Replies
I was able to find this related GitHub Issue:
https://github.com/supabase/supabase/issues/1502
At the moment, you don't have any auth schema, right?
It's only a single schema called public?
GitHub
Issues cross-referencing tables from different schemas using Prisma...
Feature request Is your feature request related to a problem? Please describe. I am trying to use Supabase together with Prisma. There seems to be a problem cross-referencing tables in different sc...
My local
prisma.schema
looks exactly as I described it above. Supabase comes with pre-defined separated schemas (public, auth, ...). I have a profiles
table defined in my public
supabase schema, that does reference users
on supabase auth
schema. (public.profiles.id
referencesauth.users.id
). Its a common setup to expose frontend facing informations for users.
When running db push
, prisma seems to introspect those tables on my db, but none of them are locally referenced in my schema anymore. The post
model isn't relying on other schemas, shouldn't it be pushed just fine?
I guess I thought db push
would just ignore tables that you don't explicitly define/reference in your local schema. Since I'm not really planning to manage/reference those tables (public.profiles
& auth.users
) from Prisma, isn't there a way to simply ignore them?How does your connection string look like?
Can you add something like
?schema=public
in your connection string and check if you still get the same error?Also, there is a
--force-reset
parameter that you could use
https://www.prisma.io/docs/orm/reference/prisma-cli-reference#options-3Prisma CLI reference | Prisma Documentation
This page gives an overview of all available Prisma CLI commands, explains their options and shows numerous usage examples.
Thx I'll check it out. Currently I decided to try and pull the data with multischema ON. It pulled the public/auth tables, and then I was able to
db push
my local models. One thing I'm not sure about is the implications of the warnings mentioning incompatibilities between prisma and supabase's postgres :
Would this prevent me from migrating, or would it override the core tables provided by supabase? When I db push
-ed, it didn't seem to brake supabase's implementation. I'm able to authenticate in my app. What if I just keep those pulled tables in my schema to make prisma happy, but never edit them? Would it risk altering anything, or slowing me down the road (apart from migrations?)