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

[whatwg] SQL API error handling

From: Scott Hess <shess@google.com>
Date: Tue, 16 Oct 2007 17:48:18 -0700
Message-ID: <696e4b7c0710161748t113e25dekddb32d21a377cb7f@mail.gmail.com>
On 10/16/07, Geoffrey Garen <ggaren at apple.com> wrote:
> > It would be nice to have a way to indicate to the script "There was
> > a catastrophic event and we reset your database, assume you're
> > starting over from scratch."
>
> In general, I'm not sure how useful it is to know that you're
> "starting over from scratch," since any database query needs to check
> its result. Presumably, an app's behavior in the "no data" case is the
> same regardless of *why* there's no data. 99% of the time the behavior
> will be to reload the data from a server.
>
> More importantly, what constitutes a corrupt database, and how to
> recover from it, are serious implementation details. Some
> implementations may have error correction algorithms. Others may have
> backups they can restore.

Either of those cases would presumably be handled transparently.

> Others may have to wipe the database
> completely and start over. Still others may not be able to start
> anything. (For example, the storage medium might have gone bad, or
> been locked or disconnected.) So, imposing a "start over from scratch"
> requirement would hamper some implementations while requiring the
> impossible of others.

I agree that we probably can't say specifically what should happen, here.

I think that if the user agent did detect corruption and nuke the
database from orbit, then it would be reasonable for the user agent to
invalidate all outstanding database handles.  But that kind of thing
would seem to be something really beyond the spec to deal with.  It
seems like at that point the most appropriate action to take would be
to refresh the page and start from scratch, rather than expecting the
app to somehow handle the problem.

-scott
Received on Tuesday, 16 October 2007 17:48:18 UTC

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