[morelish]

Sorry for being an idiot. I don't quite understand the point of the tool. You have to have two different versions (x and y) of the same database running? And you're trying to work out how the versions diverged (e.g. what sql statements you'd need to issue to change x into y)?

I'm sort of confused. Is this for people who don't know how to write database migrations? Surely not. What is this for? Sorry for being stupid.

[digitxpc]

The main use case I found was that my production database had a bunch of changes we did manually (early stage startup and all), so I used Migra to figure out what changes we needed to make to keep the migrations in sync with what was actually in production.

The more common use case is this idea in development—-experiment with different schemas manually and then use a tool like Migra to figure out what migration to write, without keeping in your head what changes you’ve made.

[ForHackernews]

This might explain it: https://djrobstep.com/talks/your-migrations-are-bad-and-you-...

It's a (IMHO) better alternative to something like Alembic https://alembic.readthedocs.org/

[morelish]

Thanks that is a helpful link.

[djrobstep]

Hello, I'm the author. There are a whole variety of uses for tools like this, some of the most common:

- Autogenerate migrations. A diff tool can (not always but very often) generate the migration script you need automatically without reference a history of migration scripts.

- Test migrations and other changes. "OK, I've run my migration script - but does prod actually match my intended production state now?"

- Quickly iterating on database designs in local development. "Just added an int column to a table in my local dev database but i meant for it to be a bigint with a slightly different name - all I need to do is update my models and run sync again."

[nicoburns]

We had an issue with our migrations at one point where we were using a “create new table, populate, drop old table, rename new table to old table” strategy for syncing data from an external source. Unfortunately our implementation flog this caused issues with indexes and constraints not being correctly propagated to the new tables, which in turn causes issues with applying migrations as a fresh database now had different indexes to our production database.

I used a tool like this to produce a diff of our prod database vs. a freshly created database with our migrations applied. Saved me a ton of time.

[jvolkman]

Tools like this allow you to keep a single desired schema up to date and then auto-generate commands to move from the current database state to desired state. So instead of manually writing 'alter table foo rename column bar to baz', you just change the column name in the 'create table' section of your golden schema and generate the alter statement.

[gregplaysguitar]

IMO the best way to use this is as a way to determine what’s changed between your canonical dB schema (well organised and easily understood DDL) and migrations (which are what gets deployed, but don’t work well as a dB reference). So you edit the schema, then use migra to generate a candidate migration for the changes which you review before deploying.

Tusker (mentioned in other comment) does it this way; my company has used the technique very successfully for several years via some lightweight tooling built around migra.

[dboreham]

Any time you have two or more supposedly consistent copies of any data set (in this case database schema), you need a tool to tell you if they are indeed consistent. Because sync schemes are seldom perfect.