I stumbled on this after commenting recently about Stellar. Sqitch was mentioned, so I decided to search for similar tools. I plan on trying them out as soon as I have time, but would be interested to hear some pros and cons from those who've used either or both.
OK, I haven't used this, but I don't see too much use in trying to revert your database the same way you do with source code. Databases are not fixed, you never restart / rerun a database in the same way you do with code, the data and schema make sense together. I imagine trying to revert a database change to be messy and unpredictable. If you need to revert back to a previous state, you might as well just restore from a backup. Then your data and schema will be correct together. Or am I missing something?
This isn't so much to revert your database, but to manage your schema migrations in a similar fashion to rake db:migrate.
Liquibase works well with Spring, so you can have the Spring context run migrations as required without involving application code. This is a very good thing. Without this, you have to have your code up your own solution for figuring out at runtime if your database schema is in line with your Entity objects (assuming your using JPA).
Definitely agree. I use liquibase so that I can check database migrations into source control and have an easy way for other developers to update to the new schema without having to understand a whole lot. It also provides a nice way to drop your whole database and recreate it if you need to.
In addition, much like how unit tests force you to think about how to write code, rollbacks help when writing schema migrations to make sure that something could be undone if necessary. In practice, I've rarely used them though, and if you do it's likely going to be on a dev/staging server.
Typically though, restoring from backup is a dicey proposition. If a schema migration causes issues down the line, you're likely to have production data that needs to be kept. E.g. a room reservation system can't just drop two days of bookings on the floor because some financial accounting table was improperly migrated. Partial restores are also difficult if you've drunk deep from the relational chalice.
On the other hand, if the upgrade was broken, it's unlikely the downgrade will work. The situation where the downgrade works is when you don't need it. On the database i work on we fix bad upgrades that weren't discovered immediately by layering another upgrade over it.
I am on MySQL and have the binary logging enabled, so theoretically I can restore a backup, then replay the commands to a point in time. I have got a job running every night to restore a copy to exactly one week ago to test it. Seems to work (Though sounds like I am operating at a smaller scale than you
South for Django has the whole migrations things stored for me, but I never see myself wanting to use it for backwards migrations.
Looks like a framework-agnostic version of Rails Migrations. Neat. Combined with git hooks could be useful - so when I merge a coworker's code I also get their schema updates.
We used this back when I worked in Brazil. Liquibase is fine and solved some of our problems keeping schema migrations in sync across developers, but I remember it lacked some essential features such as syntax correction. I remember I wrote a couple of Ruby scripts to check things for me.
The catch phrase is unfortunate, because it could trick one to think this backs your data. This is basically a Rails migrations like solution that relies on XML files to describe changes to your schema.
12 comments
[ 2.5 ms ] story [ 37.3 ms ] threadLiquibase works well with Spring, so you can have the Spring context run migrations as required without involving application code. This is a very good thing. Without this, you have to have your code up your own solution for figuring out at runtime if your database schema is in line with your Entity objects (assuming your using JPA).
In addition, much like how unit tests force you to think about how to write code, rollbacks help when writing schema migrations to make sure that something could be undone if necessary. In practice, I've rarely used them though, and if you do it's likely going to be on a dev/staging server.
On the other hand, if the upgrade was broken, it's unlikely the downgrade will work. The situation where the downgrade works is when you don't need it. On the database i work on we fix bad upgrades that weren't discovered immediately by layering another upgrade over it.
South for Django has the whole migrations things stored for me, but I never see myself wanting to use it for backwards migrations.
The catch phrase is unfortunate, because it could trick one to think this backs your data. This is basically a Rails migrations like solution that relies on XML files to describe changes to your schema.
Update: And now JSON even. Hoorray.