Re: [Refdb-devel] DB_VERSION redux

[David N. <dav...@sw...>]

Hi Markus,

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

Sounds like a brilliant idea and it gets my vote.

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

I may be a naive, but why not have a translation routine for each
increment in database version, i.e., from 1 to 2, 2 to 3, and so on.  If
refdbd found it necessary to translate from version 1 to 4, it would
sequentially call the translation routines 1 to 2, 2 to 3 and 3 to 4.
It may not be the most elegant solution, but it has the virtues that:
- number of translation routines increases geometrically with version
numbers rather than exponentially,
- it is easier to code and maintain, and
- it's hidden from the user anyway so who cares?

The longer translation time for a large version number jump is not
significant.  It is a one-off cost and most people regularly update
their systems so they will only ever jump a single version number at a time.

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

That is precisely the solution I used in the previous unitary refdb
package.  The problem with using it now is it only stops the server
package upgrading.  If the clients package is installed on the same
machine it *will* be upgraded.  The danger then is the clients and
server will be at different versions.  I assumed this would be a *BAD
THING*.  I wasn't sure the backup script, which uses refdba and refdbc,
would work if the clients were from the new package (and therefore new
database version) while the server was from the old package (and
therefore old database version).  Was I right to be worried?  If you can
guarantee the clients will always work in this situation then I can use
the previous solution of aborting the server upgrade so the user can
backup the databases before upgrading again.

I'm not sure whether such a solution is "Debian-like".  I do know it's
goddamn ugly.  Rather than gracefully upgrading the databases in situ,
the entire update (which likely involved many packages other than refdb)
fails with an error message.  This forces the user to trace back to find
the package that failed to upgrade and try to figure out the reason why.

Even if this solution is usable, I would urge you to consider it an
interim one and to implement the translation schema you postulated earlier.

Regards,
David.