I'm also in favor of Liquibase. Hibernate might be smart enough to add new columns, but to be able to for example change the type of a column, more complex data migration might be necessary. Liquibase preconditions, combined with good identifiers make up that upgrades will be more granular.
*Frank Maximus * Senior Software Development Engineer *nuage*networks.net <http://nuagenetworks.net> p: (+32) 3 240 73 81 <+32%203%20240%2073%2081> On Tue, Feb 21, 2017 at 10:31 AM Jeff Hair <j...@greenqloud.com> wrote: Something like Liquibase would be nice. Hibernate might be even better. Even idempotent migrations would be a step in the right direction. Perhaps reject any migration changes that aren't INSERT IGNORE, DROP IF EXISTS, etc? I'm not sure why the DAO was originally hand-rolled. Perhaps the original developers didn't think any ORM on the market met their needs. I would love to leave DB migrations almost entirely behind. I believe Hibernate is smart enough to construct dynamic migrations when fields are added and removed from tables, right? *Jeff Hair* Technical Lead and Software Developer Tel: (+354) 415 0200 <+354%20415%200200> j...@greenqloud.com www.greenqloud.com On Tue, Feb 21, 2017 at 9:27 AM, Daan Hoogland <daan.hoogl...@shapeblue.com> wrote: > Marc-Aurele, you are totally right and people agree with you but no one > seems to give this priority > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, Utrecht Utrecht 3531 VENetherlands > @shapeblue > > > > > -----Original Message----- > From: Marc-Aurèle Brothier [mailto:ma...@exoscale.ch] > Sent: 21 February 2017 10:04 > To: dev@cloudstack.apache.org > Subject: Re: Handling of DB migrations on forks > > IMO the database changes should be idempotent as much as possible with > "CREATE OR REPLACE VIEW..." "DROP IF EXISTS....". For other things like > altering a table, it's more complicated to achieve that in pure SQL. > A good call would be to integrate http://www.liquibase.org/ to manage the > schema and changes in a more descriptive way which allows branches/merges. > > On Tue, Feb 21, 2017 at 9:46 AM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > Good strategy and I would make that not a warning but a fatal, as the > > resulting ACS version will probably not work. > > > > On Tue, Feb 14, 2017 at 12:16 PM, Wei ZHOU <ustcweiz...@gmail.com> > wrote: > > > Then you have to create your own branch forked from 4.10.0 > > > > > > In our branch, I moved some table changes (eg ALTER TABLE, CREATE > > > TABLE) from schema-****.sql to > > > engine/schema/src/com/cloud/upgrade/dao/UpgradeXXXtoYYY.java. > > > If SQLException is throwed, then show a warning message instead > > > upgrade interruption.. > > > By this way, the database will not be broken in the upgrade or fresh > > > installation. > > > > > > -Wei > > > > > > > > > 2017-02-14 11:52 GMT+01:00 Jeff Hair <j...@greenqloud.com>: > > > > > >> Hi all, > > >> > > >> Many people in the CS community maintain forks of CloudStack, and > > >> might have implemented features or bug fixes long before they get > > >> into > > mainline. > > >> I'm curious as to how people handle database migrations with their > > forks. > > >> To make a DB migration, the CS version must be updated. If a > > >> developer > > adds > > >> a migration to their fork on say, version 4.8.5. Later, they decide > > >> to upgrade to 4.10.0 which has their migration in the schema > > >> upgrade to 4.10.0. > > >> > > >> How do people handle this? As far as I know, CS will crash on the > > >> DB upgrade due to SQL errors. Do people just sanitize migrations > > >> when they pull from downstream or somehting? > > >> > > >> Jeff > > >> > > > > > > > > -- > > Daan > > >
