Flyway 3.2 Released – Database Migrations Made Easy | Hacker News Reader

Flyway 3.2 Released – Database Migrations Made Easy

flywaydb.org

24 pointsaxelfontaine13 comments

At work, I introduced the concept of automated migrations (as opposed to "let's do it by hand" and "stored procedures are a great solution") with Flyway. It has been a great success, even though the project needed to support multiple databases, which Flyway does not handle (but its API is easy to work with).

I'm not entirely sure of what it does with out-of-order migrations (eg, "master' has migration A,B,C, and "legacy" has had A and C backported - I'm not sure if Flyway will gracefully apply B on a "legacy" database when switching it to "master"), and the docs do not seem to mention this use case.

It will work as expected if you set the ... (you guessed it) outOfOrder flag to true.

Flyway pre-1.0 user here (since 2010). It's a really nice and simple tool.

Liquibase, the other major migration tool in Java, offers platform-independent database migrations but this requires you to write migrations/query's in XML. Flyway supports plain SQL, much easier for everyone (dev, DBA, etc) involved.

It's always great to hear from someone who's been happy with it from its humble beginnings! Thank you for having been an early adopter!

I've had such positive experiences with FlyWay. It's well-documented, works across all the JVM-based languages, and now based on the latest packaging, it looks like it can be easily used in non-Java projects. Great work @axelfontaine.

Feedback truly appreciated Josh :-)

I've been learning Flyway and so far it seems to work well for applying handwritten sql scripts. I was hoping it could generate the migration files for you based on your entity classes, but that doesn't seem to be the case. Is there any tools for Java that handle both applying migrations and generating migration files based on your JPA Entity classes?

I've been using Alembic with SQLAlchemy with Python and I really like the ability to auto generate migrations and then be able to hand tune them if need be. I'm looking for the same kind of tooling for Java and haven't really been able to find it yet.

While that approach may seem convenient at first, I recommend the exact opposite for two reasons:

1. Your data will outlive your application

2. I strongly prefer contract-first over code-first interfaces between systems for stability and reliability issues

Following the latter, as the interface of your database towards your application is the schema, you should absolutely have that being the driving force and not the entity classes in your language of choice

I watched this video https://www.youtube.com/watch?v=vPwWQvvBWEg where (I think you?) explained these points in greater detail and I tend to agree with you that sql first is a very sensible approach.

I'm probably missing something, but is there a configuration with JPA that can explain the tables that hibernate's expecting based on the Entity classes? I guess that's where my biggest pain point going from sql first to writing my classes is getting the tables to validate and map properly. It's been a little time consuming being new to the ecosystem trying to get my sql (postgres) to map to JPA Entity classes going in reverse. Going from Entity classes to SQL you don't have this issue because the tool is writing the SQL for you (not saying this is the best approach) so without this a tool for debugging Entities would be handy to get up to speed faster when using Flyway or another SQL first approach.

You might want to take a look at the Grails Migration Plugin (which uses Hibernate and Liquibase "under the covers")

It allows you to write your domain classes in a Groovy DSL, called GORM http://grails.github.io/grails-doc/latest/guide/GORM.html and generate SQL and SQL migrations as you change your classes.

Here's the Getting Started page from the documentation http://grails-plugins.github.io/grails-database-migration/do...

There is a standalone GORM that allows you to use the Groovy DSL without Grails, I'm not sure how the Migration plugin could be made to work with that.

Thanks! I'll take a look at that.

Looks interesting, but to me "database migrations" means something far more boring and well catered for already (etl tools etc), hence I almoat didn't bother looking at the site. From a quick perusal I'd call what flyway is doing more like 'database version management'.

You are absolutely correct. The term migrations is something we took over from the Rails folks who are largely to credit for popularizing this essential practice: http://edgeguides.rubyonrails.org/active_record_migrations.h...

Reply on news.ycombinator.com