On Mon, Feb 11, 2013 at 2:55 PM, Kyle Huey <[email protected]> wrote:
> On Mon, Feb 11, 2013 at 10:40 PM, David Grogan <[email protected]>wrote: > >> When chrome opens an IDB database, it attempts to detect corruption. If >> the database appears to have been corrupted, either via software bug or >> hardware fault, chrome performs "recovery." As currently implemented (we >> may try to do something more surgical in the future), "recovery" >> means removing all the origin's databases from disk and creating a new >> empty database. It would be useful to alert script that some data has been >> lost in this situation. The web app could then alert the user or take other >> appropriate action. This is important in offline editing scenarios, where >> this represents true user data loss rather than just a flush of a data >> cache. >> > > Do you expect to ever be able to implement something more granular than a > per-database recover or discard? I would imagine that's as surgical as it > is going to get. > We've talked about checkpointing, which would allow chrome to recover everything except the last N commits. > I think the answer to that question impacts how we design this. > I'm assuming you mean because a surgical recovery could leave the version intact and make a new property on the upgradeneeded event inaccessible? In that case we could also put the property on the success event that comes in response to open().
