https://www.prisma.io/ logo
Join Slack
Powered by
ok, indeed, I was able to modify the schema direct...
# orm-help
j
ok, indeed, I was able to modify the schema directly then 
npx prisma db pull
and that seems to have updated my schema.prisma but it hasn’t generated a migration, I don’t think
r
@James Pickard 👋 
db pull
will not generate a migration. Migrate commands like 
migrate dev
need to be run on adding an index to 
schema.prisma
.
j
why on earth does prisma insist on deleting all my data when I create a migration? it seems unnecessary
I simply added a unique constraint, and trying to create a migration files does this
Copy code
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": MySQL database "deck-builder" at "localhost:3306"

Drift detected: Your database schema is not in sync with your migration history.

The following is a summary of the differences between the expected database schema given your migrations files, and the actual schema of the database.

It should be understood as the set of changes to get from the expected schema to the actual schema.

[*] Changed the `slide_decks` table
  [+] Added unique index on columns (name)
Copy code
✔ We need to reset the MySQL database "deck-builder" at "localhost:3306".
Do you want to continue? All data will be lost. … no
r
The reason is that you have duplicate values in the field you want to make unique. I just tried this on a field with no duplicate values, added 
@unique
and ran 
prisma migrate dev
. This is output and it doesn’t drop anything:
j
Ah interesting that it’s possible to do it without dropping data. I don’t have duplicate values, but I do already have the index (because I added it in order to be able to use 
prisma db pull
). Removing the index and running 
prisma migrate dev
seems to work. I’m guess I’m struggling with the correct dev workflow.
It seems a bit odd to add an index directly, use 
prisma db pull
, remove the index, then run 
prisma migrate dev
r
I don’t know why did you opt for 
prisma db pull
in the first place. It’s just for development (prototyping) and not included in the Migrate flow. What you need to do is: 1. Add the index to the field in your 
schema.prisma
2. Run 
prisma migrate dev
(make sure no duplicate values exist on the field) If you have duplicate values, you just need to remove them via a script before running 
prisma migrate dev
. The rest remains the same.
j
ah, so the intention is to modify 
schema.prisma
directly. The reason I used 
prisma db pull
is because it’s easier and more natural for me to add an index using MySQL syntax, or a GUI, than to figure out the prisma schema. It would be cool if this workflow were supported.
It would also be neat if this workflow were covered in this article, perhaps at the end a section about “adding constraints to an existing schema” or something https://www.prisma.io/docs/guides/general-guides/database-workflows/unique-constraints-and-indexes/mysql
r
We have one here that shows how to work with Migrate (like adding new fields)
9 Views
Open in Slack
PreviousNext
Powered by