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
