Supabase Auth latest gotrue migration impossible to resync using Prisma migrate about auth HOT 3 CLOSED

We can leave this up if you guys want but I'm very relieved I was able to solve this issue on my own. I needed to add the schema declaration (auth.) to the enum on creation like so:

in my migration.sql, otherwise it would appear it was attempting to add the enum to the default schema which would make sense when you look at the duplicate enum in the drift detection error screenshot above.

Note: I also had to add schema declaration (auth.) the one_time_tokens.token_type column as shown here:

otherwise you would get this error on migrate:

All in all consider this issue solved and an oversight by me (best possible outcome), hopefully it helps anyone who has to keep the auth schema in sync in response to supabase making changes. You can't just copy the migrations from this repo:

https://github.com/supabase/auth/blob/master/migrations/

change the namespace to auth and call it a day. As the changes get applied to your Supabase instances and cause prisma to detect drift, you have to carefully consider the code going in those migration.sql files and the changes you make to your schema.prisma as well.

Again, consider this issue solved. Archive it if you feel like it can help people or let me know if you want me to delete it.

Thanks.

from auth.

We strongly recommend not using Prisma or anything else to touch anything in the auth schema. You can very easily break your Supabase Auth server, and we may not be able to help you recover data if you do so.

We are seeing quite a lot of problems caused with this, so in the mid-term it is very likely we will implement some measures that would prevent you from touching the auth schema at all. You would be able to turn this off, at your own risk.

from auth.

For clarity, we don't "touch" the auth schema we reference the users.id outside of the auth schema which is supported per the docs for anyone using supabase auth.

I do suggest not giving up on this because it does allow for a robust and efficient development team experience. I would go as far as working with the prisma team to allow a schema like auth to be referenced but not "managed" in the same way prisma wants to strictly manage all included schemas.

If I weren't able to use prisma do you have plans to create or support a first/third party tool kit primarily as a way to manage changes in a development supabase environment (db schema's, RLS policies, functions, triggers, etc.) and deploying them to a production supabase environment?

To put it another way, If I started a new suapbase env I could have it set up in minutes thanks to the prisma schema and migrations I have in our codebase. This is the type of functionality we will be looking for.

I appreciate your feedback and look forward to your response.

from auth.