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

[whatwg] SQL API error handling

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 15 Oct 2007 21:07:01 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0710152105390.19595@hixie.dreamhostps.com>
On Fri, 5 Oct 2007, Scott Hess wrote:
>
> Reviewing SQLite's error list, the things that MAY have utility to 
> report more finely might be:
> 
>  * LOCKED, where you failed because someone else has things locked. 
> Presumably if a single thread of control tries to open the same database 
> via two objects and start two transactions, one of them is going to 
> lose.  Having a transaction fail for this reason seems materially 
> different from having it fail because the SQL was invalid or something 
> of that nature, because the appropriate response might be to retry.

Wouldn't we just want the transaction to wait for the lock to go away?


>  * CORRUPT, insofar as the Database API lets you delete databases (it 
> doesn't currently, but we've thought of adding that to Gears).

Do we expect authors to actually test for this? Wouldn't the better 
behaviour upon finding that the database was corrupt just be to inform 
the user and wipe it clean? I don't think we want random sites dealing 
with user-side corruption, surely.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 15 October 2007 14:07:01 UTC

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