Jeff, I do wonder the same thing about the ORM... I hit the ORM limitation in many places now without being able to do joins on the same table specifically for capacity check, and you can see in the code many hand made SQL query on that part. I think the views came into the pictures for the same reason.
Daan, the project maintainers should enforce that. I also posted another finding that the upgrade path are not identical due to the order in which upgrade files are executed, see (https://github.com/apache/ cloudstack/pull/1768) 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 > 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 > > > > > >
