+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
