`prisma delete` doesn't actually delete the database

[zwhitchcox]

Describe the bug I get the error There is a relation ambiguity during the migration. Please first name the old relation on your schema. The ambiguity is on a relation between Service and Trade. Please name relations or change the schema in steps.

I don't even know what the previous name was or really have any idea what the relation was in my old schema, and I have no way of getting the old schema back, because I was just messing around and didn't save it.

But anyway, I don't even really care what the old name was, because I'm not using that schema or data at all anymore. So, the solution was to delete the database.

I deleted it with prisma delete --force, but when I try to launch the database again, it still gives me the same error.

Considering the whole database was supposed to be deleted, it seems like there shouldn't be an error regarding migrations. It did not give me an error or anything when I deleted the database, and I've tried to delete it multiple times, and it still gives me the same error when I try to launch the new schema.

To Reproduce I don't have the old schema anymore, as I said, so I don't really know how to reproduce this or give you the current data in my database.

Versions (please complete the following information):

• Connector: MySql
• Prisma Server: 1.31.0
• prisma CLI: 1.31.1
• OS: Windows 10

Additional context https://www.prisma.io/forum/t/how-do-i-completely-delete-the-prisma-database/6825

[zwhitchcox]

possibly related to #4450

[zwhitchcox]

I've confirmed that after I delete it, the database is still completely there, because all the docs are still there when I go to http://192.168.99.100:4466

[pantharshit00]

prisma delete deletes the prisma service. To get rid of your data use prisma reset command

[zwhitchcox]

I am trying to delete the service. What I'm saying is when I do prisma delete, it doesn't delete the service.

[pantharshit00]

Ok, let me explain this properly:

First of all, you will need to understand that we store all of your migrations metadata and service metadata in a separate database(called prisma in case of MySQL connector) in your database server. prisma delete command will remove your service metadata from this database. It will NOT touch your data and the database which your service is using. We do it as you may still need your data but you don't want the API exposing your data. Once the service metadata is deleted, it will not show up in prisma ls or any equivalent command.

While on the other hand prisma reset command will wipe your service database.

So in order to completely remove your service run along with the data, run:

prisma reset -f
prisma delete -f

[adammichaelwilliams]

Ok, let me explain this properly:

First of all, you will need to understand that we store all of your migrations metadata and service metadata in a separate database(called prisma in case of MySQL connector) in your database server. prisma delete command will remove your service metadata from this database. It will NOT touch your data and the database which your service is using. We do it as you may still need your data but you don't want the API exposing your data. Once the service metadata is deleted, it will not show up in prisma ls or any equivalent command.

I believe the behavior you're describing is incorrect for Postgres with Prisma v1.33.0.

When I run prisma delete -f locally, the entire schema is removed (data, tables, everything). This behavior is different for remote hosts where nothing seems to happen. I believe this is related to: https://github.com/prisma/prisma/issues/4312#issuecomment-489457258

For more information, see #4581

[targoo]

Same issue for me when trying to delete/reset a remote hosts.

[omar-dulaimi]

Prisma is stuck on deploying, it deploys the changes and when deploy again it deploys the same changes. I tried to reset and delete but wasn't successful. Please, how can I delete it completely?

[omar-dulaimi]

For whoever will get stuck in the future, here's how I debugged the issue: First go to your migrations table in your database and check the state of the last migrations. You'll find that they're failing due to some constraints on schema like NULL in my case.