`prisma migrate dev --create-only` executed previously created migrations

Bug description

prisma migrate dev --create-only commits migrations previously created with --create-only. This is not exactly a bug, but it’s unexpected behavior. I should be able to decide when to commit my migrations to the database.

How to reproduce

1. Create a migration with prisma migrate dev --create-only
2. Change your schema
3. Create another migration with prisma migrate dev --create-only
4. First migration is committed to the database.

Expected behavior

I expect the command --create-only to only create a migration and do nothing else.

Prisma information

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["nativeTypes"]
  binaryTargets   = ["native", "rhel-openssl-1.0.x"]
}

Environment & setup

• OS: Catalina 10.15.7
• Database: Postgresql
• Node.js version: 12.22.1

Prisma Version

Environment variables loaded from .env
prisma                  : 3.1.1
@prisma/client          : 3.1.1
Current platform        : darwin
Query Engine (Node-API) : libquery-engine c22652b7e418506fab23052d569b85d3aec4883f (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli c22652b7e418506fab23052d569b85d3aec4883f (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core c22652b7e418506fab23052d569b85d3aec4883f (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt c22652b7e418506fab23052d569b85d3aec4883f (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : c22652b7e418506fab23052d569b85d3aec4883f
Studio                  : 0.423.0
Preview Features        : nativeTypes

[jeremygottfried]

Mostly it’s the behavior I expect. For example, with rails/rake there were always two steps to migrating.

First you create the migration:

rails generate migration

Then you migrate the data:

rails db:migrate

This wouldn’t be as important if prisma had a rollback command for migrations, but either way I expect this level of control for organizing db changes. For example, if I’m creating 3 tables, I’d prefer for them to each be in separate migrations (for naming and code standards), AND I need the option to dynamically update them before committing all 3. Currently, I’d have to create the migrations manually to do that.

[weslord]

(While I’m at it, I’d also like to address this thought from https://github.com/prisma/prisma/issues/5553#issuecomment-873588154)

This is meant to be happen in the context of your development database, applying migrations there is the bread and butter any time you run migrate dev and the way it’s conceived you should even be ok with resetting the database often. Applying migrations could be unexpected perhaps but should not be perceived as danger or drama.

Yeah, it’s not as dangerous as losing data on production. But a big part of my full-stack workflow involves populating my dev database in the course of developing and trialling new front-end features. I build up with bunch of new data that’s directly relevant to the features I’m working on, covering the various extremes I want to handle. It’s not coming from a seed script or copied from production.

If I unexpectedly lose a column or a table, it’s not the end of the world. To be honest, the data is generally nonsense. But it’s my nonsense data! And hey, I was using that! I’d at least like a warning so I can decide if it’s worth making a quick backup copy, rather than spend half an hour generating brand new temporary nonsense.

Sure, sometimes even complete resets on dev are easier or inevitable. But when Prisma detects database drift, it suggests a reset and offers a choice… even though it’s just the dev database.