cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@shapeblue.com>
Subject RE: Handling of DB migrations on forks
Date Tue, 21 Feb 2017 09:27:11 GMT
Marc-Aurele, you are totally right and people agree with you but no one seems to give this
priority

daan.hoogland@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, Utrecht Utrecht 3531 VENetherlands
@shapeblue
  
 


-----Original Message-----
From: Marc-Aurèle Brothier [mailto:marco@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.hoogland@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 <ustcweizhou@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 <jeff@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
>
Mime
View raw message