Hi Markus,
The change in database version in svn has exposed some problems. First,
use of refdba and refdbc has not caused /var/lib/refdb/db/DB_VERSION to
increment from 1 to 2. I've restarted the refdbd daemon and run clients
as root but it stays at '1'. I haven't yet investigated log messages.
The second problem is more complex. It has to do with how the packaging
system handles an upgrade in database version. You may recall the
unitary refdb package handled this by having the pre-install script
compare database versions of new package and existing package. If the
new database version was higher, then the user was urged to abort the
upgrade and backup all data. The backup and restore scripts could
assist. The upgrade abort was achieved by having the pre-install script
exit with a non-zero status. This forced the package manager to abort
the upgrade.
Now refdb is split into clients and server packages. Only the server
package has the version-checking machinery. If both clients and server
packages are running on the same machine, the clients package updates
but the server package update may be aborted. This may result in the
application being unable to access *any* reference data.
The most obvious solution is to use the pre-install script to force a
data backup (by, say, refdb-backup) and use the post-install script to
restore the data (by, say, refdb-restore). The problem is the server
package may be running on a computer without the clients package. The
backup and restore scripts require the refdba and refdbc clients
supplied by the clients package. In fact, since both clients are used
in backing up and restoring reference data, neither operation can be
done on server-managed data in the absence of the clients package. The
relevant client executables cannot be packaged into both packages under
the same names as this is forbidden by all package managers. Forcing
the server package to be dependent on the clients package would,
however, defeat the purpose of splitting refdb into multiple packages in
the first place.
What this problem cries out for is a data conversion utility that ships
with the server package and can be called by pre- and/or post-install
scripts to upgrade all databases in-place and without user involvement.
A "poor man's" approach would be to move the backup and restore scripts
from client package to server package. The server package would also
need renamed copies of the refdba and refdbc clients (as they are called
by the backup and restore scripts).
When DB_VERSION was first added to refdb you declared it to be a "slimy
hack". Perhaps now is a good time to implement a more robust solution.
Having fixed the documentation problems, I am now reluctant to post a
new svn debian package until this "migration" issue is resolved.
Regards,
David.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
|
