Hacker News Reader

Comment by evangow | Hacker News Reader

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?

View on HN

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.

Wouldn't a dump and then diff of the schema into text form accomplish the same thing?

Or something a bit more high-level like Migra? https://github.com/djrobstep/migra

It absolutely should, though you might want to have a specific set of questions you ask in an ordered fashion as things like column order might differ between production and development due to data sizes, dropping and recreating dev instead of migration, etc.

None of those things actually being a problem could give you false positives, so you might want some minor shuffling.

You might be interested in the service I'm building, which does a similar thing in a more structured way: https://djrobstep.com/ci-for-databases

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.

Doesn't your RDBMS support transactions?

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.

Reply on news.ycombinator.com