3 ms·
Flyway 4.1.0 released
- endymi0n 10y agoAwesome work, Axel - Flyway is our absolute go-to tool for all migrations, very easy, straightforward and one of only two pieces of Java in our stack that's so good we let it stay :)
- gred 10y agoDon't leave us hanging! What's the other?
- endymi0n 10y agoElasticSearch - definitively the least bad large scale full-text search server out there... (BTW: Flyway FINALLY supports non-transactional PostgreSQL migrations now, been waiting for that for ages!)
- axelfontaine 10y agoThanks! Truly appreciated!
- axelfontaine 10y agoFlyway creator here. Happy to answer any questions. Enjoy the release :-)
- 3adawi 10y agoone of the things i hate most about my job is db migration, didn't know this existed, gonna give it a try
- MBCook 10y agoI was in the same boat with a little home-grown thing that worked.... ok. Then a coworker showed me FlyWay. It's great.
- donpdonp 10y agoWe use flyway with a scala project at work and it does a great job! It was working with ruby on rails that taught me one of the strongest reasons to use psql over over databases - transactional schema changes. If a migration fails I absolutely want the whole migration rolled back so that the schema can be fixed and tried again. Which is why this paragraph is alarming: "First Flyway now autodetects whether a non-transactional statement is present within a migration. If it is, then the whole migration is run without a transaction (and clearly labelled as such in the logs)." Arguably, mostly devs working with psql dont know that its possible to create schema change commands that cannot be transactional, myself included. I imagine creating such a statement 'by accident' is exceedingly rare, but a default of allowMixedMigrations to false seems more sensible to be 'default safe'. I say 'safe' because a broken, half-executed migration can leave a real mess. Thanks for your efforts and for the flyway project!