Feature Request: Hasura Cli export stored migration files

I’ve accidentally deleted a particular set of migration files, and am left in a state as such:

VERSION        SOURCE STATUS  DATABASE STATUS
1562644590462  Not Present    Present

Unfortunately, there doesn’t appear to be a way to export this file from the database. I’ve found a blog describing how to reset the migrations, but exporting a particular migration seems like a common enough use case.

I would love to see an interface such as:

$ hasura migrate export <version>

[coco98]

@jjangga0214 @scribahti Thanks for your detailed notes and ideas 😃

The primary issue, which is that of losing migrations can be solved by resetting all the migrations. Get the entire postgres schema and the hasura metadata.

We’ve thought about storing the migration files on hasura also, but the reason we went against that is because it creates lots of different sources of truth viz. 1) the state of the database and hasura metadata, 2) the migration files on the filesystem and the new one 3) Migrations stored on the database. Managing all 3 together and keeping them in sync becomes painful.

The current approach (inspired by rails like migrations say) is to treat the migration files that are on the filesystem like “source code” files that are either written by hand or generated by the console and then apply them to the database to modify the database state.

If one loses the migration files, it’s akin to losing source code. Also, it’s not a complete failure, because since the database has the latest state anyway, you can always reset from scratch. Ofcourse, resetting will cause loss of all the incremental changes and so on.

It seems like this is a problem that git or a version control system should solve. Exporting/importing and sharing migrations are git tasks now. This is how most migration systems behave.

@jjangga0214 @scribahti Does this make sense? The recommendation is to use git to make sure you don’t lose the migration files 😃 Would love your thoughts!

[jjangga0214]

I’ve just found there is a table hdb_catalog.schema_migrations, which only has two columns version(bigint) and dirty(boolean). (By the way, what is the role of dirty? There’s no docs for hdb_catalog.schema_migrations) @scribahti and I assumed a virtual table named migrations on the above discusstion, and I think hdb_catalog.schema_migrations is actually the right table, which this issue(#2488) should be applied to.