Re: [IndexedDB] Inform script of corruption recovery

Yes, for v2.
Kyaw


On Wed, Jun 12, 2013 at 2:25 AM, Arthur Barstow <art.barstow@nokia.com>wrote:

> Hi - your comment is considered a "Last Call comment" and it was included
> in the LC's comment tracking document [1].
>
> In [2], Joshua proposed this comment be addressed/resolved as a feature
> request and as such, it was added to the IDB feature request list [3].
>
> For the purposes of tracking your comment, please indicate if this
> resolution is acceptable or not.
>
> -Thanks, ArtB
>
> [1] <https://dvcs.w3.org/hg/**IndexedDB/raw-file/default/**
> Comments-16-May-2013-LCWD.html<https://dvcs.w3.org/hg/IndexedDB/raw-file/default/Comments-16-May-2013-LCWD.html>
> **>
> [2] <http://lists.w3.org/Archives/**Public/public-webapps/**
> 2013AprJun/0817.html<http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0817.html>
> >
> [3] <http://www.w3.org/2008/**webapps/wiki/**IndexedDatabaseFeatures<http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures>
> >
>
>
>
> On 5/19/13 11:14 PM, ext Kyaw Tun wrote:
>
>> It will be good, if we can provide data priority per database and/or per
>> object store.
>>
>> Web app already assume Indexeddb data is temporary, recovery process are
>> in place at the beginning after database is successfully open. So silently
>> drop all data and set version to 0 is good way to go. I think detail reason
>> are not necessary.
>>
>> After opening, database should not corrupt. But quota exceed error do
>> happen. It is very difficult and messy to handle that issue.
>>
>> If these corruption happen, data are lost according to their priority
>> will be good enough for most situation. It is easy for both sides
>> (developer and browser implementation).
>>
>> Kyaw
>>
>
>