W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] database full error (was: Re: executeSql API issynchronous)

From: Kristof Zelechovski <giecrilj@stegny.2a.pl>
Date: Sun, 14 Oct 2007 10:29:33 +0200
Message-ID: <000001c80e3c$59479830$1a01080a@POCZTOWIEC>
It is possible to recover from a database full error.  You can dump the data
to a slower device for example.  While this action would not make the
database operable again, you would at least avoid losing data.
Best regards,
Chris

-----Original Message-----
From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Scott Hess
Sent: Friday, October 12, 2007 9:07 PM
To: WHATWG Mailing List
Subject: Re: [whatwg] database full error (was: Re: executeSql API
issynchronous)

On 10/12/07, Anne van Kesteren <annevk at opera.com> wrote:
> I think there should be an error code for the database being full. For
> some platforms there's not much storage space available and knowing
> whether or not there's some space left is useful. So you can decide to
> only store the critical data for instance.

My counter-argument to this is that by the time you get the "database
is full" error, you're probably already sunk.  Most likely there won't
be anywhere to store the critical data, either.  Assuming your
database has transactional semantics, you may not be able to delete
any data, because it will need more space while implementing the
delete.  You MAY be able to delete an entire database, except that
there's currently no API to do that, and on some platforms even that
may be challenging (on some systems, anyone with an open connection to
the database will likely prevent deletion.  On others, anyone with an
open connection will likely prevent reclaiming of the deleted space).

I think what you're really asking for, above, is a means of saying
"How much data can I store?", so that you can make decisions about
what to store.  In the limit, that's hard for the browser to
guarantee, of course.

-scott
Received on Sunday, 14 October 2007 01:29:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC