Re: Managing application and database version dependencies
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
RE: Managing application and database version dependencies
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
Re: Managing application and database version dependencies
As soon as I read 'compatibility number' in your email I remembered we discussed this internally long ago. Just recently I was thinking of tracking the required version for each app that connects to the database but after thinking about it I don't think we'll need that level of granularity. A single compatibility number kind of forces us to keep all the apps in line, and I think there's some benefit to that as it would help to avoid scenarios where we have a mix of several different app versions trying to work together. Thanks! On Fri, May 7, 2010 at 2:24 PM, 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
Re: Managing application and database version dependencies
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
