Declarative schema migrations#38
Conversation
jack-brinkman
left a comment
jack-brinkman
left a comment
There was a problem hiding this comment.
Love your work as always 😎
| The generated migration file should be reviewed and modified if it needs tweaking. | ||
|
|
||
| This is called a 'versioned migration' process according to atlas. Basically it generates imperative migrations in the `migrations` folder like a traditional schema migration tool would, except that those files are generated by doing a diff between the 'last' state of the schema to the new one. | ||
| Which gives us the best of both worlds, declaritive schema management while still being able to review and approve individual changes in pull requests. |
There was a problem hiding this comment.
This is really cool! To clarify - does the schema.sql added in this PR represent the database schema in its current up-to-date state, or an earlier state? If it's the current up-to-date state, should we clean out all the individual incremental migrations generated by diesel?
There was a problem hiding this comment.
yep, the current up to date state.
we should clear out the diesel migrations yea. it's just a bit tedious because i don't want the ci/cd to fail during that transition as we'll need to make a separate change to the kubernetes manifests to use the new migration tools. will do a further cleanup pr once it's all up and running
| ``` sh | ||
| diesel print-schema | ||
| # bash | ||
| diesel print-schema > src/schema.rs |
There was a problem hiding this comment.
Is there some cheeky automation we could do for this so it's executed after we atlas migrate apply --env arga
There was a problem hiding this comment.
good idea! nothing turnkey that i'm aware of. would be really nice though because i'm gonna forget to run that all the time. I could add a script in devenv so that it'll do everything with a simple create-migration add_my_table in the meantime
| // we shorten the type here for readability | ||
| pub type IntArray = Vec<Option<i32>>; | ||
|
|
||
| #[derive(Clone, Queryable, Debug, Serialize, Deserialize)] |
There was a problem hiding this comment.
Are the deletions below (sorry I picked a bad line to comment on) just old / unused tables? I love a good cleanup 🧹
There was a problem hiding this comment.
Yea they are. some of them were still being used in a graphql endpoint as well but they are definitely empty tables and shouldn't be used anymore
2 participants
This PR collects all the migrations done to date into one
schema.sqlfile and makes it the source of truth.It also added support for atlasgo.io versioned migrations so that we can still review and edit specific migrations that are generated by the atlas tooling.
In addition to setting up a baseline migration to start using declarative migrations this PR also removes a bunch of dead tables and code as a test case for the new tooling.