`--dev-mode` option on `edgedb migrate` serves two very different purposes
- Dominant language
- Rust
- Stars
- 175
- Forks
- 32
- PR merge metrics
- No merged PRs in 30d
Description
`edgedb migrate --dev-mode` seems to both apply transient schema changes _and_ lock in those changes, which is a bit confusing. Hers's a scenario:
I create a new project. I add some baseline schema, create a migration, and apply it. Then, I want to iterate on it a bit. I make some changes to my schema. I use `edgedb migrate --dev-mode` to apply those changes without creating a migration.
I iterate some more and apply more migrations in dev mode. Now, I have the schema the way I want it, and I'm ready to lock it in. I run `edgedb migration create` to create the migration. Then, to transition my dev mode changes into proper migrations in the database, I need to run `edgedb migrate --dev-mode` again, but the thing I'm doing is different than it was the first time I ran the command with the `--dev-mode` option.
The first time I migrated in dev mode, I was creating what might be a transient change in the database's schema. Now, I'm doing the exact opposite of that — locking in a formerly transient change — but the command is the same. It feels counterintuitive.
I propose that we switch the final "lock in" `migrate` command to either a naked command (`edgedb migrate`) or a command with a different switch (perhaps `--apply-dev-mode` or something similar). I prefer the naked command if it's practical since, once the migration is created from the dev mode schema changes, the user is in the same scenario as if they had never used dev mode at all, so using the same command they would have used to migrate in that case seems intuitive.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.