Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better Database Migrations in Postgres

craigkerstiens.com

Post reply on HN
Print view View original

11–20 of 89 posts

Re: Better Database Migrations in Postgres

#11

Post by sbuttgereit »

Cieplak wrote: post #10

Sqitch is a pretty useful migration tool: http://sqitch.org

I like the whole sqitch approach much better than that provided by most migrations (if I'm in migration land, I use https://flywaydb.org/). From the version control perspective you get the sprawl of changes across files like you do with migrations.

I find that, for tables, if I write anonymous "DO" blocks in a single script to manage both the initial creation of the table and any later deltas, I get a very satisfactory version control history. This is a bit different than the recommended approach (if I'm not mistaken).

I just wish it wasn't written in perl with 10,000 cpan dependencies which may or may not build in a given circumstance.

Re: Better Database Migrations in Postgres

#14

Post by sandGorgon »

misframer wrote: post #2

strong_migrations looks like a really useful tool. Are there similar ones for languages/frameworks besides Ruby/Rails?

Alembic is a standalone tool written in Python. Having spent years on rails migrations and then using Alembic, I can say that alembic is really brilliant. It behaves like git - it has a branching and merge model for Migrations (in case multiple people work on it simultaneously).

Re: Better Database Migrations in Postgres

#16

Post by oneweekwonder »

sbuttgereit wrote: post #11
Cieplak wrote: post #10

Sqitch is a pretty useful migration tool: http://sqitch.org

I like the whole sqitch approach much better than that provided by most migrations (if I'm in migration land, I use https://flywaydb.org/ ). From the version control perspective you get the sprawl of changes across files like you do with migrations. I find that, for tables, if I write anonymous "DO" blocks in a single script to manage both the initial creation of the table and any later deltas, I get a very satisfact…

Another options is liquibase[0]. I use the diff[1] tool to create a changeset and then convert it to sql before applying it to my db. liquibase keeps a log and lock table in your db so you can always review the changeset you applied to the db at a later time.

[0] http://www.liquibase.org/

[1] http://www.liquibase.org/documentation/diff.html

Re: Better Database Migrations in Postgres

#19

Post by iaabtpbtpnn »

fulafel wrote: post #7
neeleshs wrote: post #4

Earlier quoted context omitted.

For JVM languages, Flyway is quite popular (flywaydb.org) Django (python) has a builtin migration tool

It works well as a command line tool, so not even restricted to JVM languages. One strong point of Flyway, besides being "just SQL", is the repeatable migrations, you can update your stored procedures, views and table documentation in the same version controlled source files without making a new copy in a new migration file for each change.

Oooh I use Flyway but did not know about this feature! It solves a big problem for me, thank you for mentioning it! :)
Post reply on HN