How do I migrate down? (revert migration)

[arogozhnikov]

Sorry if missing something obvious, but search did not show anything helpful.

CLI does not understand command to migrate to a specific version in the past, insisting that "revision XXX is the ancestor of the latest YYY".

I use migrations to first migrate multiple times in local/dev db, and then roll them back if ideas did not work.
Or if I need to reorganize migrations (e.g. put multiple migrations into one, or visa versa).

[tailhook]

There is no way to migrate down so far. You can revert your schema (either with editor or git) and create another migration.

Also you can try the new migration workflow #4682 if you want. It doesn't require creating migrations for experimentation. But you have to install nightly command-line tool and newer server for that:

> curl --proto '=https' --tlsv1.2 -sSf https://sh.edgedb.com | sh -s -- --nightly
> edgedb project upgrade --to-version=3.0-alpha.1

[arogozhnikov]

if reverting schema and creating a new migration, is there way to "squash" a number of migrations? Some of migrations potentially drive to losing data / format, and removing them from history is important.

question #4682 about changing type from @raddevon I think should be addressed. Given how frequently I just move fields around, delete fragments of code, I need to deeply understand which migrations are auto-applied before going that direction.

[arogozhnikov]

or maybe there is a way to 'stamp' database as in sqlalchemy when system is forced to believe it is currently in a state X.
This way I could revert schema files, migrate, remove several predecessing migrations, and stamp db to the original state.

[tailhook]

if reverting schema and creating a new migration, is there way to "squash" a number of migrations?

In 3.0 yes. Although, we probably don't have UI for that at the point of the release except within the boundaries of #4682, which should become the primary way of developing anyways.

question #4682 about changing type from @raddevon I think should be addressed. Given how frequently I just move fields around, delete fragments of code, I need to deeply understand which migrations are auto-applied before going that direction.

We'll see how far we can go. But generally, we assume that if something is dropped in dev-mode it's fine (i.e. this is how "move around" would work).

or maybe there is a way to 'stamp' database as in sqlalchemy when system is forced to believe it is currently in a state X.
This way I could revert schema files, migrate, remove several predecessing migrations, and stamp db to the original state.

If I understand you correctly, this is what START MIGRATION REWRITE is (#4562). But I encourage you to play with #4682 first.