[Refdb-devel] DB_VERSION redux

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > 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.
 > 

They should be informative. Just grep for "version file". Let me know
what you find. The upgrade did work on my box. DB_VERSION contains a
'2' here without any manual intervention.

Anyway, we had to bump into this problem eventually. I prefer this to
happen now (between prereleases) than during a release.
 
 > 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).
 > 

This is not much different from saying "the server package depends on
the client package". Maybe we have to face it for the moment.

An entirely different solution is to let refdbd handle the upgrades
internally. refdbd would have to retain the ability to read old-style
databases, save the data to temporary tables, alter the database
schema, and write the data back into place. This is doable, although
it requires quite a bit of coding. It may turn out to be a nightmare
to maintain in the long run, as I'd have to test an increasing number
of combinations (1->2, then 1->3 and 2->3, then 1->4, 2->4, 3->4 and
so on) before releasing a new backwards-incompatible version.


 > 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.
 > 

Yup. Lesson learned. Sooner or later, all hacks will start to haunt
you.

 > Having fixed the documentation problems, I am now reluctant to post a 
 > new svn debian package until this "migration" issue is resolved.
 > 

I guess it is not Debian-like to abort the installation if the
database needs to be updated and ask the user to backup his data?
Instead of upgrading you'd have to deinstall the old package and
reinstall the new one, followed by restoring the data. The problem is
that I badly need some feedback about the new citekey citation style
which only works in the SVN version...

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de