This is a very cool project, but I'm not sure exactly what I would use it for. I could see it being useful if didn't start your project out using a tool for schema migrations and need to back reverse engineer things to create fake migrations.
I'm curious, does anyone here use it that would care to explain their use case?
We use it in our CI, just before deployment, to compare the DB structure of what's being tested with the DB structure of our staging or production environment.
It's a last minute check that prevented a lot of mistakes.
It seems like it could be used for declarative schema management (like https://www.skeema.io/) where you define the table structure you want in code and the application diffs a database and performs whatever changes is needed to reflect the requested schema.
I'm using it generate a "flush_database()" stored procedure (after applying the latest migrations), that means each "before each" of a test can "execute flush_database" to get a clean slate db for its boundary case (w/o having to know/lookup "oh we've got 10-20-50 some entity tables now").
So, yeah, just custom/minor infrastructure/tooling stuff that is based on the db schema.
I have a similar project called `schemainspect` - It creates a data structure representation of a postgres schema.
I then use this data in my database diffing project `migra`, to autogenerate database migrations. You can also use schema diffing to test that your production and development databases match explicitly.
Overall it's a much more flexible but rigorous approach than the old-fashioned rails/django migrations.
I've made something similar which I use for two things. 1) I create typescript types from my schema, and 2) I run a "linter" over my schema that validates a number of rules that I've created. It's been a great help honestly.
paps|6 years ago
It's a last minute check that prevented a lot of mistakes.
djrobstep|6 years ago
larkost|6 years ago
sciolistse|6 years ago
stephen|6 years ago
So, yeah, just custom/minor infrastructure/tooling stuff that is based on the db schema.
aargh_aargh|6 years ago
djrobstep|6 years ago
I then use this data in my database diffing project `migra`, to autogenerate database migrations. You can also use schema diffing to test that your production and development databases match explicitly.
Overall it's a much more flexible but rigorous approach than the old-fashioned rails/django migrations.
unknown|6 years ago
[deleted]
kristiandupont|6 years ago