incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Chan <will.c...@citrix.com>
Subject RE: schema maintenance
Date Tue, 14 Aug 2012 00:58:32 GMT


> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, August 13, 2012 5:36 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: schema maintenance
> 
> On Mon, Aug 13, 2012 at 8:06 PM, Darren Shepherd
> <darren@godaddy.com> wrote:
> > Has there been any talk about not maintaining a monolithic
> > create_schema.sql and doing a more DB migrate style?  From a
> > supportability perspective its way easier if your SQL is just always
> > deltas from the last.  For example, you ship version 1 and create
> > schema1.sql.  Version 2 you add some stuff so you create a schema2.sql
> > that adds what you need to the database (just delta).  So if somebody
> > installs from scratch they run schema1.sql and schema2.sql.  If you
> > already have version 1, you just run schema2.sql.
> >
> > This is an extremely common approach and cuts down the need to test
> > the DB from scratch and upgrade.
> >
> > Darren
> 
> +1 - I'm a huge fan of this, based on lots of time using the Django /
> Python world's South framework [1].  That approach supports schema and
> data migrations, rolling forwards and backwards.  It might not be possible
> to easily get to that level of sophistication, but it makes operation of an
> environment much easier.
> 
> However, there does come a time when the total number of migrations gets
> out of hand.  I'm not sure we can get away without a "create db"
> script that essentially does 80% of the schema build...
> 
> -chip
> 
> [1] - http://south.aeracode.org/

CloudStack has effectively done that for upgrade scenarios.  You'll see things like schema-3.0.0to3.0.1.sql
files.  It includes both the incremental DB changes from one version to the next but also
includes migration scripts as well.  We also kept the monolithic schema file for convenience
but I doubt it will be that much work to simply call all the upgrade SQL rather than that
single file.  

The only part is I agree with Chip that after some time, it could get big and slow to apply
all those sql files if you were to start from scratch.  From a development point of view,
that single create-schema.sql file deploys much faster than 30 separate sql files and I assume
it will just get slower as time progresses.

Will

Mime
View raw message