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
