Custom java code to manage the database is every DBAs worse nightmare. I'd be very very interested into moving to an off the shelf DB migration tool. I'd recommend flyway given the fact that CloudStack only supports mysql and is very SQL DDL oriented as it stands.
I'll probably look into this a bit later. I know personally if I had to deploy DB updates this way to production, I would not be a happy admin. If you find you have to do crazy weird DML for an upgrade that's only possible in java I'd probably say your doing something wrong. Worst case scenario create a proc that does the update and then drop the proc. You need to have all migrations in SQL files such that a DBA can review them. For upgrades you should be able to keep java code v1 running and run the upgrade to DB v2. Then deploy java v2 code. Having to shutdown and big bang do DB and java is too risky of a deployment. Many many companies separate application and DB to completely different teams. Not to mention runtime DB user has DML rights. Ever tried to pass an audit with stuff like that, yikes. Darren On Aug 27, 2013, at 10:00 PM, Prasanna Santhanam <t...@apache.org> wrote: > On Tue, Aug 27, 2013 at 04:48:02PM -0700, Darren Shepherd wrote: >> It seems like on startup of the management server >> DatabaseUpgradeChecker runs and upgrades the database performing DDL >> and DML. Is there a way to upgrade the database that doesn't >> include starting the management server? > > This would be a *massive* boon to all the upgrade testing. Running the > upgrade without having the server to be up using a db versioning tool > like liquibase/dbmaintain. This had come up before and I remember > talking to Alex who had explored such tools and found them unsuitable > at the time. > > There are parts of the upgrade that alter database rows (IIRC) which > is done using java code. These run only when the server is running and > cause this coupling. These are file that start Upgrade*.java > > -- > Prasanna., > > ------------------------ > Powered by BigRock.com >
