Re: [IndexedDB] Inform script of corruption recovery

jsbell pointed out an annoyance with this approach. If we delete the entire
backing store while opening a database, we can alert the page that that
particular database was lost via the mechanism discussed in this thread.
But if there are two databases lost then the opener of the second one is
out of luck: when a request is made to open the second database, e.g. a day
later, IDB won't know that it once existed so won't know to alert the page.
Meaning that we can only provide this notification on a best-effort basis.

On Mon, Feb 25, 2013 at 10:56 AM, Kyle Huey <me@kylehuey.com> wrote:

> On Tue, Feb 12, 2013 at 1:49 PM, David Grogan <dgrogan@chromium.org>wrote:
>
>>  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().
>>
>
> Well I was thinking more like being able to recover one object store and
> not others.  But this does raise an interesting question.  If we can
> restore to the same db version, but not identical contents, how would we
> indicate that to the page?  Is there anything more useful we can provide
> than "someDataWasLost=true"?  Doesn't seem like it.
>

Given that we can probably only provide a notification on a best-effort
basis it would seem silly to try to provide a detailed message in those
times where we did notify.


> - Kyle
>
> (Sorry for the delay responding, been on vacation).
>