From: Franky V. L. <lie...@te...> - 2008-03-31 17:46:17
|
On Sun, 30 Mar 2008 17:49:35 -0400 Matthew Gregg <mat...@gm...> wrote: > More thoughts about the DB update. If the version that the DB > reports is the same as the version in the code, i.e. the schema > versions match, then the DB update should do absolutely nothing. > This makes giving the super-user the ability to do the update less > "scary" and should work for Bishop's use case no? Hi, this is already the case. Once the update is done, no second update is possible (since the versions match). See my comment below as well. > Bishop, you could update the phpESP code, immediately login as the > super user and do the DB update. Then your user, super-users, could > click update all day long and nothing would happen other than a page > that says DB is already up to date. > > This brings up another issue we should handle, if the schema is > mismatched, we should report on the admin side that the DB needs > updating and then on deployed survey side, that submissions cannot be > done at this time. If the versions mismatch, the only thing you can do on the admin side is execute the update (all other links are not visible). Once the update is done, the update link no longer shows and everything is back to normal. I can add the same logic to the survey side if wanted. But what do you normally do when updating? Maybe we should just have a file called "disabled" or so, and as long as that file is there, all surveys appear offline (something like "The system is undergoing an update, please be patient"). What do you think? Franky |