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 -- zeitgeist fails to run if its database structure is not complete https://bugs.launchpad.net/bugs/660307 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
