I’m currently in the process of starting a new project, so I’m trying to figuring out how to manage my db schema.
I see that liquibase can handle the incremental updates of the db schema. That’s great! But how will this look like in a few years? Will my project be flooded by hunderts of little changes leading back though all minor and major versions down to the empty schema?
This seems a bit strange to me. So how does liquibase handle the situation when I (or even more importantly, the customer) create a fresh database? Will it migrate it though the hole history of the project?
In previous projects I managaged sql-change-scripts manually. Basically at every release (~every week) I exported a sql script that created the complete schema from scratch. During the week incremental scripts were written. What I liked on that is that we had (at least for every release) a complete, selfcontained schema description.
Can you give me a bit of insight on how liquibase should be used for a multi-year project?
We’ve been using Liquibase for over a year now. I’ll see if I can’t share my experiences and help out a bit.
For fresh installs Liquibase will replay every single change in your changelog. Even though it’s a little cumbersome, this doesn’t take as long as you might think. Upgrades are quick, though.
One BIG caveat that I can offer is that you should avoid custom refactorings like the plague. Some of our developers took a liking to them and now that we’re trying to upgrade to liquibase 2.0 they’re causing nothing but heartache and woe.
I really don’t like the full replay. Maybe I’m overestimating this. But with CI, thats an operation which will run dozens of times a day. And the idea of delivering the complete project history to customers is also not very appealing to me.
I had a short look at that oracle tutorial. That 14 page monster gave me a headache ??? I’ll look at it again when I’m well-rested ;D
From what I’ve seen its quite complicated and includes manual steps, possibly even oracle specific. I can’t see the advantage here at the moment.
The oracle tutorial is a bit of a monster. Lots of stuff in there, not all of it always works well or makes sense for everyone.
I tend to be in favor of the full replay because that is the path that has been tested previously. It’s easy when trying to combine steps together to introduce errors, and I find the the (generally small) overhead of replaying the well-tested steps to be much less painful that the possible bugs that can be introduced by changing them. If there are particularly expensive operations that can be combined there are options (mainly removing the old changeSets and creating new ones with tags).
