Re: upgrading the main database

Hi Markus,
> To check the connection to the database engine and to read out the
> version of the main database, run something like this:
>
> refdbd -c -D sqlite3 -e 0 -l 7 -i /path/to/db 2>&1|grep "version:"
>
> refdbd will display some messages and exit. Similarly, to upgrade an
> existing main database, run something like this:
>
> refdbd -a -D sqlite3 -e 0 -l 7 -i /path/to/db

The easiest thing to do from a packager's point of view would be to run 
this command unconditionally as part of the postinstall process.  The 
reason is that it is difficult to tell the new db version immediately 
after installation but before the daemon has been started.  Can running 
the upgrade after each server upgrade cause harm?  I hope refdbd is 
smart enough to know when an upgrade is unnecessary and can be skipped.

> David, if you use the latter in your Debian package postinstall
> script, you may have to explicitly name the database engine and the
> default database location as shown here because the user may have
> changed these settings in refdbdrc after the package was installed. Of
> course you'd run it without dumping the debug log messages to the
> screen.

The postinstall script already checks /etc/refdb/refdbdrc for an 
alternate dbpath.  It is a simple matter to also check the database engine.

> In order to make the upgrades possible in future releases I've
> versioned the refdb dump files. That is, refdb.dump.sqlite(.in) was
> renamed to refdb.2.dump.sqlite(.in) and so on. Future releases will
> probably have to provide several dump files of older database versions
> in order to allow upgrades from these older versions.

The postinstall script checks for a main refdb database.  If none is 
found it automatically creates a main sqlite database using the sqlite 
dump.  Now that you have versioned the dump files it will be difficult 
for the postinstall script to know which dump file to import.  I could 
include a loop in which it checks each refdb.[ver].dump.sqlite and 
determines the largest 'ver'.  It would be easier, however, for me (and, 
I presume, other packagers) if the newest dump file had a predictable, 
stable name.  Could you call the newest version 'refdb.dump.sqlite' with 
only older versions numbered?  When the newest version is replaced it 
would then be renamed to include the version number and the replacement 
(now the newest) would receive the unversioned name.  Alternately, and 
to avoid any possible confusion, the newest dump might be called 
'refdb.newest.dump.sqlite' or 'refdb.latest.dump.sqlite'.

Regards,
David.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV