Re: [Refdb-devel] upgrading the main database

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

Hi David,

David Nebauer <dav...@sw...> was heard to say:

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

You can do just this. If refdbd -a notices that the installed main database is
already at the latest version, it does nothing.

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

I was thinking along these lines too. I think I'll reverse the current filenames
to refdb.dump.sqlite and version only the older ones.

regards,
Markus


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