4 ms·

Flyway 3.2 Released – Database Migrations Made Easy

24 points by axelfontaine 12y ago

codeulike 12y ago
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'.
- axelfontaine 12y ago
  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.html http://edgeguides.rubyonrails.org/active_record_migrations.h...
nek4life 12y ago
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.
- axelfontaine 12y ago
  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
  - nek4life 12y ago
    I watched this video https://www.youtube.com/watch?v=vPwWQvvBWEg 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.
- msgilligan 12y ago
  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 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/docs/manual/guide/gettingStarted.html 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.
  - nek4life 12y ago
    Thanks! I'll take a look at that.
mercurial 12y ago
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.
- axelfontaine 12y ago
  It will work as expected if you set the ... (you guessed it) outOfOrder flag to true.
rickette 12y ago
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.
- axelfontaine 12y ago
  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!
joshpadnick 12y ago
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.
- axelfontaine 12y ago
  Feedback truly appreciated Josh :-)

24 points by axelfontaine 12y ago

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'.

axelfontaine 12y ago
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.html http://edgeguides.rubyonrails.org/active_record_migrations.h...

nek4life 12y ago

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.

axelfontaine 12y ago
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
- nek4life 12y ago
  I watched this video https://www.youtube.com/watch?v=vPwWQvvBWEg 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.
msgilligan 12y ago
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 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/docs/manual/guide/gettingStarted.html 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.
- nek4life 12y ago
  Thanks! I'll take a look at that.

mercurial 12y ago

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.

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

rickette 12y ago

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.

axelfontaine 12y ago
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!

joshpadnick 12y ago

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.

axelfontaine 12y ago
Feedback truly appreciated Josh :-)