Re: [IndexedDB] Inform script of corruption recovery

On Thu, May 9, 2013 at 4:01 PM, David Grogan <dgrogan@chromium.org> wrote:

> 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.
>

To clarify, chromium stores all databases for an origin in a single leveldb
instance, so this is a real possibility for us.


> 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).
>>
>
>