zeitgeist team mailing list archive

[Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxx>]

However noble it may be I don't think we stand a realistic chance of
implementing a stable "repair" function if the DB corrupts at an
undefined point in the upgrade process. There are just *way* too many
variables if we have fx. 4 different DB schemes that can all intermix
and corrupt in different ways.

I'd rather we simply made the N -> N+1 transition more reliable. A few ideas:

 a) Implementing a validation step after an upgrade has completed and
taking appropriate measures if it fails (fx. by using c) below)
 b) Back up the DB before starting the upgrade. I recommend that we
back up to a gzipped ttl file because that can be used in a streaming
(aka appending) way
 c) Implement "recover from backup" (see point point b))

These are all relatively simple measures that can be properly unit
tested and are much more limited in the ways they can fail