-----Original Message-----
From: Will Chan [mailto:will.c...@citrix.com]
Sent: Monday, August 13, 2012 9:19 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: schema maintenance
Just need a volunteer to make this switch. Alex, perhaps someone on
your
team?
Will
________________________________________
From: Darren Shepherd [dar...@godaddy.com]
Sent: Monday, August 13, 2012 8:53 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: schema maintenance
Why don't we decide that the 4.0 release is last release this way
and then
going forward everything will be delta since 4.0.
Darren
> -------- Original Message --------
> Subject: Re: schema maintenance
> From: David Nalley <da...@gnsa.us>
> Date: Mon, August 13, 2012 8:22 pm
> To: cloudstack-dev@incubator.apache.org
>
>
> +1 for this. I'd ditch the monolithic altogether.
>
> On Mon, Aug 13, 2012 at 11:10 PM, Will Chan <will.c...@citrix.com>
wrote:
> > No argument from your thoughts on this. I think if the project
wants the
incremental DB changes, CS is already in a good position to support
that
through our upgrade sql scripts.
> >
> > Will
> >
> > ________________________________________
> > From: Darren Shepherd [dar...@godaddy.com]
> > Sent: Monday, August 13, 2012 6:18 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: cloudstack-dev@incubator.apache.org
> > Subject: Re: schema maintenance
> >
> > Understood, but I would venture to guess that developers (and a
lot of
testing) work off of the create_schema file and then prepare the
upgrade as
an after thought. That means the likelihood of issues in the
upgrade is higher.
I've just personally seen that the monolithic file gets more people
looking at
it and essentially tested more.
> >
> > Having been a customer of CloudStack in the past I can tell you
that old
release + delta did not always match the current create_schema.
> >
> > The concerns of the deltas getting to be too much is simply
solved when
you get to that point. In practice the time it takes to run a bunch
of deltas to
create a DB from scratch is not much slower than the monolithic file
because
DDL runs real fast on an empty DB.
> >
> > Darren
> >
> > Sent from my iPhone
> >
> > On Aug 13, 2012, at 5:58 PM, Will Chan <will.c...@citrix.com>
wrote:
> >
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Chip Childers [mailto:chip.child...@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
> >>> <dar...@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
