Shouldn't be a problem. At least, we've thought about how this should work before. I might even have a bug for it.
The one that I really have not thought through and I have raised on this list and worth raising again is the following. CloudStack Plugins generally will have some tables that are specific for it. We have now put each plugin into its own project so it makes sense that portion of the schema should go with the plugin as well. This brings up two problems. 1. Not every plugin gets deployed in every deployment so if it's one giant schema, a lot of tables will go unused. That's still acceptable to me. 2. What I'm not sure of is how to support the updates of these plugin tables. Any suggestions? --Alex > -----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
