-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prisma Migrate Drops Custom Migrations #24180
Comments
What exactly is the destructive migration that is being generated here? Fundamentally the problem is that Prisma does not support what you are trying to use in Prisma Schema (a generated column I think), and hence will of course try to clean up your database to bring it into the state that the Prisma schema represents. But that is also why |
The "destructive actions" generated by Prisma that I mentioned are -- DropIndex
DROP INDEX "idx_search";
-- AlterTable
ALTER TABLE "Video" DROP COLUMN "search"; I realize that |
We would love to be able to offer that, but how should Prisma know what is expected in the database (because of a manually modified migration) and what is not (and hence needs to be fixed to get to the desired state)? If I was you, I would probably add the |
One possible solution is to tag each migration to the corresponding Prisma schema. Then a newly generated migration would diff the changes in the Prisma schema, as opposed to diff against what is in the current database. This, I believe, makes a bit more sense and is in my opinion a better system overall, but I understand it is likely time consuming to implement. As for your solution, how can I add the column/index to the Prisma schema? Since |
Yes, but that would be pretty much a completely different migration tool than what Prisma Migrate currently is.
I was thinking about adding it as a supported field, and then manipulate the migration that would create it. But you are correct, in the details this might not actually work as hoped :/ |
@ApocalypseCalculator, you might be interested in #24248, in which I suggest we make diffs based on changes to the Prisma schema in different git versions. You might be able to use this for your use case. |
Bug description
For a multitude of different reasons users need to use custom SQL for unsupported Prisma features. One such feature I am trying to implement is native full text search, which requires me to add a tsvector column to my table and a GIN index. The documentation outlines how to customize a migration, which has worked for me. However, I am now trying to create another table, and when I try to create a migration for it, the generated migration drops my custom column and index.
Since my development database was populated with test data, I was able to catch on as Prisma warned of its attempt to push these changes onto the database itself. However, without data in dev, there is no warning and the migration is generated straight away. If deployed to production, this would wipe out the data I had, which is not really acceptable.
I believe that Prisma should a) warn of destructive actions like dropping columns/indices before generating migrations and b) not have this issue of dropping in the first place. Thoughts?
How to reproduce
prisma migrate dev --create-only
Expected behavior
Prisma shouldn't drop my custom migration
Prisma information
Environment & setup
Prisma Version
The text was updated successfully, but these errors were encountered: