Open vasilakisfil opened 10 months ago
Hi, and thanks for your interest! Can you give a practical use case for this change?
Old migrations may fail to apply correctly, or even be possible to get applied at all, if those migrations use changing external dependencies or rely on application code which evolves separately from the migrations.
Schema is the source of truth, and it is also committed to the repo. Figuring out the state of the db (relations, constraints etc) from migrations is impossible. The only way is to run the migrations and query the db. However, having the schema in the repo, helps a lot even on repo discussion (issues, PRs) as you can reference a part of it directly.
It tends to be faster and less error prone to create a new instance of the application's database by loading the schema file directly than it is to replay the entire migration history.
yeah makes sense, I think we can have a function in the runner that dumps the schema would you be interested in implementing it?
Migrations are just diffs over time, not the final state of the database schema nor the source of truth. The actual database schema, after running all migrations, is the source of truth. Is there a way to get that using refinery, in an sql or barrel format ?
I guess an alternative is to use pg_dump and specify
--schema-only
but would be great if refinery could extract that from all migrations somehow.