It is also worthwhile to check the environment at the same time, I have a flag for development test and production, you do not want to run tests against your production database!
On Fri, May 7, 2010 at 3:06 PM, David Richards <ausdot...@davidsuniverse.com > wrote: > I have a "Version" table that has a single column, single row with a > version number in the form A.B.C.D. I started doing this to follow > the same version standard as my apps. So the number would be: > > A - Breaking change > B - Non breaking change (eg additional table, additional column with > default) > C - No interface change (eg an index) > D - only included to have the same format > > In practice though, pretty much every change I've ever had to make has > been a breaking change so a single number would have been just as > good. I still use the format though, just for the sake of being > standardised. > > > David > > "If we can hit that bullseye, the rest of the dominoes > will fall like a house of cards... checkmate!" > -Zapp Brannigan, Futurama > > > > > On Fri, May 7, 2010 at 14:24, Greg Keogh <g...@mira.net> wrote: > > Matt, I like to put two magic numbers in a special database table: The > > change number, The compatibility number. > > > > > > > > The first increments whenever the schema changes. The second increments > only > > when a “breaking” change is made. > > > > > > > > The app startup code can use these numbers to determine if it can run or > > not, or perhaps to run in a crippled way (but I haven’t needed that yet). > > > > > > > > Your needs are probably far more complicated that I describe, but my tiny > > humble system at least forces you to think about keeping the code and DB > > working together. > > > > > > > > Greg >
