Re: [IndexedDB] Inform script of corruption recovery

On Mon, Feb 11, 2013 at 10:40 PM, David Grogan <dgrogan@chromium.org> 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.  I think the answer to that question impacts how we design
this.

Some options we've discussed:
> * Do nothing; web apps could mirror the latest version in localStorage and
> look for discrepancies.
> Pro: No changes to the IDB API.
> Con: Lame to make web developers rely on another storage mechanism to
> handle IDB corruption.
>

This is a) terrible and b) ineffective.  Why wouldn't LS be subject to
similar corruption problems?  In Firefox we currently use SQLite as the
ultimate backing store for both LS and IDB, but even if we were using
different backing stores, I wouldn't see any reason to choose the *less*
reliable one for IDB.  That said, we shouldn't be promoting LS for
anything, certainly not for limitations of IDB.


> * Report to the user via pop-up, not script
> Pro: No changes to the IDB API.
>  Con: Opaque to the web app. Not actionable to the user. Prevents any
> app-level appropriate response.
>

The user can't do anything useful with this information.


> * Property on the upgradeneeded event. If a corrupt database was blown
> away, oldVersion would be 0 but a "reason" property could indicate
> corruption; and similarly,
> * Property on IDBDatabase indicating if recovery had to be performed
> during opening (e.g. "dataLoss" with values "none", "total", and
> potentially "partial")
> Pro: Surfacing error to the app allows for app-specific action or options
> presented to the user.
> Con: Not very elegant, the extra property is wart-like.
>

This is my preferred alternative.  Setting the property on upgradeneeded
makes the most sense, IMO, because recovering from corruption is a
transitory state, not one associated with the IDBDatabase indefinitely.


> * Change open flow - in case corruption is detected, open fails with
> diagnostic error, but can be retried by script e.g. indexedDB.open(name,
> version, { recover: true }) - i.e. what chrome does automatically/silently
> for scripts today
> Pro: Gives app control over how to handle corruption.
> Con: Complex. Until implementations perform a nuanced recovery, the extra
> control isn't terribly useful.
>

The opening flow is complex enough already.  I would hesitate to make it
more complicated.


> We've been leaning toward the extra property on IDBDatabase or the
> upgradeneeded event but are interested in hearing opinions.
>

Of the identified options an extra property on upgradeneeded is by far my
preferred choice.

- Kyle