My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 1033: RFE: K9 should handle internal database upgrade failures more gracefully
3 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  jes...@gmail.com
Closed:  Aug 2013


Sign in to add a comment
 
Reported by Saul.Tan...@gmail.com, Jan 14, 2010
What steps will reproduce the problem?
1. Upgrade K9
2. Encounter an unanticipated database upgrade problem
3.

K9 database upgrade code should catch unanticipated SQL and/or IO problems,
and, as a last resort, offer to delete and recreate the local store.

While I'm sure the code could be made even more graceful than that, just
that sort of catch all would be great improvement over any sort of manual
recovery mechanism.

Jan 14, 2010
Project Member #1 jes...@gmail.com
(No comment was entered for this change.)
Owner: jessev
Labels: -Priority-Medium Priority-Critical
Mar 24, 2010
Project Member #2 cketti
 Issue 1032  has been merged into this issue.
May 3, 2013
#3 av8r.m...@gmail.com
At 3,000 messages (approximately) with the app taking approximately 140MB of memory for its data (still had >12GB free), the app began running sluggishly. At around 3,500 messages, the app froze a few times and finally after perhaps the 4th or 5th hang, it took down the System User Interface. I had to restart the tablet and when I did, all messages were gone. The app is now using 400KB for the 5 messages (none have attachments, so I'm not sure why they need even THAT much space). I tried grabbing screen shots, but the OS was in such a bad state that I couldn't. My problems were with 4.200, not due to an upgrade as described in the OP.
Aug 18, 2013
Project Member #4 jes...@gmail.com
cketti has done significant work to make database upgrades more robust for 4.4
Status: Fixed
Sign in to add a comment

Powered by Google Project Hosting