Database updates
From Pirates@Home
This page is deprecated. The funtionality described here has been added to BOINC, but the implemenation is different.
One reason BOINC projects may not update their software regularly is that a part of the process is (or should) include applying database updates. This process is tedious. The updates come in a single file, html/ops/db_update.php, with each update encoded in a function with a name of the form update_dd_mm_yyyy(), where dd, mm, and yyyy are the day, month and year of the update. Unless you have kept a separate record of which updates you have already applied, you have to go through the list and determine "by hand" which ones are new. (I have kept track of the updates by commenting them out in the file once they have been applied, but if you upgrade your project before doing the updates the upgrade will overwrite the file and you loose that information!)
As a result of this, projects either don't upgrade, don't upgrade as often as they should, or don't apply database updates when they upgrade (unless something breaks during the upgrade).
This process could easly be automated. The main idea is:
- When each update is applied, log that fact to a file (kept in the project log directory)
- Before an update is to be applied, check the log file to see if it has already been applied. If so, politely decline the update.
Once this process is automated, it could even be added to the upgrade script.
Implementation
Each database update is applied using a function called do_query(). I have created a modified version of this function which implements the steps above. You can download it from http://www.spy-hill.net/~myers/help/boinc/db_update_util.php
To use this to automate your database updates, simply edit the file html/ops/db_update.php. Remove the definition there of the function do_query() and replace it with
require_once("db_update_util.php")
The log file, called db_update.log is kept in the project log directory. It will be created if it does not already exist. Each line in the log file represents an update which was succesfully applied, marked with a timestamp, and the Unix name of the person who ran the update.
Some database update functions involve more than one SQL query. Each query is recorded separtely in the log file, numbered from 1 onward.
Getting Started
The first time you use this scheme you can add the names of update functions already applied to the log file, one per line. They don't need a time stamp or any other information, but the fact that the update function name appears in the file while inhibit application of that update. So the first time you do this you have to put the same effort into manually figuring out which updates have been applied and which have not. After that, subsequent updates do not require as much effort.
