geldata / geldata/gel-cli

`--dev-mode` option on `edgedb migrate` serves two very different purposes

Open
#1,182 0 comments 1 reaction 1 assignee Claimed by @fantix View on GitHub
enhancement
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.