|laziness, impatience, and hubris|
Re: Need advice about database-migration for my dbix::classby Rhandom (Curate)
|on Jun 26, 2013 at 03:30 UTC||Need Help??|
This isn't a dbix problem directly. This applies to most databases in general. There are two options: cut over which includes downtime, or slow migration without downtime.
In the cut over, your code and your database move at exactly the same time.
A variation of the cutover can be used if you have decent db error handling, and hopefully have automated schema migration. In that case you deploy your code, and let a few errors occur while you update your database. This method only works if database errors are acceptible and your schema size is small.
In the slow migration you go like this.
A variation of this last scheme is to change your code to detect which version of schema you are using and make appropriate db calls.
The last scheme is much more difficult to execute, but can easily be done in stages with a zero downtime. At places I work we have used this mechanism for 15 years (well, percona is a recent improvement). Figuring out which is best is your call. There isn't a one size fits all solution. Yet.
my @a=qw(random brilliant braindead); print $a[rand(@a)];