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
Oh, and one point in I forgot to add in my previous comment - I don't
want to validate the DB on startup. That's just way too expensive -
and whas in fact one of the primary points when I implemented DB
versioning.
One thing we could do to easily, and almost freely, detect when we are
killed
To replicate this
1) Backup the activity.sqlite DB
2) restart the daemon
3) while its saying DEBUG:zeitgeist.sql:Updating sql schema kill the
daemon
On Fri, Nov 12, 2010 at 8:13 PM, Seif Lotfy
660...@bugs.launchpad.netwrote:
I manged to replicate this manually creating an invalid structure.
I found an issue...
The tables are generated if not existent on each startup
However if the table exists but is damaged or incomplete it wont overwrite
it
We can fix that by getting the columns for each table and replacing if
incomplete
Does that sound sane?
On Fri, Nov 5, 2010 at 4:49 AM, Rocko
4 matches
Mail list logo
