3 ms·

This is what Liquibase does. It does some other stuff for you as well, quite simple ones, but time has proven (to me/us) that they're all useful in real-life sc

This is what Liquibase does. It does some other stuff for you as well, quite simple ones, but time has proven (to me/us) that they're all useful in real-life scenarios: - exclusive lock to prevent multiple instances running at the same time - rollbacks - forcing immutability > Then spends two days fiddling with config files to get it working. Look, dozens and dozens of developers have been using this for many years at us without problems. If it takes two days to set it up: let it be. And we're writing our migration scripts in SQL, not XML.

mumblemumble 6y ago
So, having used both, I've got to say, I had fewer problems with the homegrown solution. Liquibase has its share of gotchas, especially in the SQL syntax. My sense is that most of the problems I experienced had to do with weird edge cases introduced by trying to handle some complex enterprisey scenario that I would rather deal with by just not letting things get that complicated in the first place. That exclusive lock mechanism, for example, isn't foolproof, and I suspect that it has bitten me more times than it's helped me. -but- Roll-your-own is not necessarily the easy option. I'd say that, if your goal is to get something robust enough to use in production, a day to implement is a very optimistic estimate. I'd say that it's one to steer clear of unless you're sure you know what you're doing. Which one is better depends, as usual, on your situation. I think my rubric would probably be: If the XML schema definition language is at all attractive to you, use Liquibase (or similar). That's far and away its most unique contribution. If, on the other hand, the knowledge that anyone would even consider defining their SQL schema in a language other than SQL fills you with holy rage, maybe choose an option that sits closer to the metal. This doesn't necessarily need to be DIY project, but, thanks to Zawinski's Law, that might be the only way to ensure that your solution also stays close to the metal.
- redis_mlc 6y ago
  I've used both home-grown and Liquibase. You have to use something to create, approve and apply patches if you're subject to compliance audits. I found Liquibase helpful for dev and integration environments where deploy pipelines can easily apply sequences of database patches automatically. But for large-scale production masters, you end up applying patches at certain times after hours (6 pm PT but not on Friday), automatically under 400,000 rows on SSD, and manually if the tables are large. Often patches are applied out-of-order (typically I'll do smallest to largest tables, or no-FKs then FKs, least-busy to most-busy tables, on-calls online or not, ordered by backup timestamp, etc.) The above is one of the main reasons to hire a DBA, and Liquibase alone cannot replace that. Source: DBA.

mumblemumble 6y ago

So, having used both, I've got to say, I had fewer problems with the homegrown solution. Liquibase has its share of gotchas, especially in the SQL syntax. My sense is that most of the problems I experienced had to do with weird edge cases introduced by trying to handle some complex enterprisey scenario that I would rather deal with by just not letting things get that complicated in the first place. That exclusive lock mechanism, for example, isn't foolproof, and I suspect that it has bitten me more times than it's helped me. -but- Roll-your-own is not necessarily the easy option. I'd say that, if your goal is to get something robust enough to use in production, a day to implement is a very optimistic estimate. I'd say that it's one to steer clear of unless you're sure you know what you're doing. Which one is better depends, as usual, on your situation. I think my rubric would probably be: If the XML schema definition language is at all attractive to you, use Liquibase (or similar). That's far and away its most unique contribution. If, on the other hand, the knowledge that anyone would even consider defining their SQL schema in a language other than SQL fills you with holy rage, maybe choose an option that sits closer to the metal. This doesn't necessarily need to be DIY project, but, thanks to Zawinski's Law, that might be the only way to ensure that your solution also stays close to the metal.

redis_mlc 6y ago
I've used both home-grown and Liquibase. You have to use something to create, approve and apply patches if you're subject to compliance audits. I found Liquibase helpful for dev and integration environments where deploy pipelines can easily apply sequences of database patches automatically. But for large-scale production masters, you end up applying patches at certain times after hours (6 pm PT but not on Friday), automatically under 400,000 rows on SSD, and manually if the tables are large. Often patches are applied out-of-order (typically I'll do smallest to largest tables, or no-FKs then FKs, least-busy to most-busy tables, on-calls online or not, ordered by backup timestamp, etc.) The above is one of the main reasons to hire a DBA, and Liquibase alone cannot replace that. Source: DBA.