On Thu, 18 Oct 2007, Scott Hess wrote:
We don't have error codes for the DOM has become corrupted or for
the Window object's properties have become corrupted, why do we need
one for the Database's contents are corrupted? Why can't the
database contents simply not be corrupted in the
On 10/17/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 15 Oct 2007, Brady Eidson wrote:
In some embedded (and client-server) database implementations -
including SQLite - continuing to operate on a database that is known to
be corrupt can lead to the process crashing. Unlike the CPU
: WHATWG
Subject: Re: [whatwg] SQL API error handling
Corruption in the database isn't the fault of the user agent. I
consider it at the same level as corruption on disk - or even a full
disk!
As I consider these to be similar, I assert that database corruption
is an external force the user
Garen
Cc: Scott Hess; Maciej Stachowiak; Ian Hickson; WHATWG
Subject: Re: [whatwg] SQL API error handling
INVALID_STATE_ERR is already overloaded and I think the corruption
case is a particularly problematic one - I guess what I'm after is a
special condition for the corruption case built
On Wed, 17 Oct 2007, Křištof Želechovski wrote:
Aside: the net gain from shortening INVALID_STATE_ERROR to
INVALID_STATE_ERR is 2/19; is it worth sacrificing readability for 11%
length?
The exception names are decided by the W3C's DOM working group(s), I
recommend raising the issue with
On Mon, 15 Oct 2007, Brady Eidson wrote:
In some embedded (and client-server) database implementations -
including SQLite - continuing to operate on a database that is known to
be corrupt can lead to the process crashing. Unlike the CPU core just
overheated case, it is a dangerous state
I don't feel quite passionately enough about this issue to pursue it
with much more vigor, but will make one remaining point:
On Oct 17, 2007, at 6:58 PM, Ian Hickson wrote:
On Mon, 15 Oct 2007, Brady Eidson wrote:
In some embedded (and client-server) database implementations -
including
On 10/15/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 15 Oct 2007, Scott Hess wrote:
Whoa! I just realized that there's another group, constraint failures.
These are statements which will sometimes succeed, sometimes fail. As
currently spec'ed, it looks like a constraint failure will
perhaps it would be prudent to change the spec to at least suggest
that if a database becomes known to be corrupt, operations on all
open handles to that database should start throwing
INVALID_STATE_ERR exceptions.
I think this is already specified:
3. If transaction has been marked as
On Oct 16, 2007, at 11:29 AM, Geoffrey Garen wrote:
perhaps it would be prudent to change the spec to at least suggest
that if a database becomes known to be corrupt, operations on all
open handles to that database should start throwing
INVALID_STATE_ERR exceptions.
I think this is
perhaps it would be prudent to change the spec to at least suggest
that if a database becomes known to be corrupt, operations on
all open handles to that database should start throwing
INVALID_STATE_ERR exceptions.
I think this is already specified:
3. If transaction has been marked as
On Oct 16, 2007, at 2:08 PM, Geoffrey Garen wrote:
After all active transactions are cleared, there is no context that
remembers that the database is corrupt, and the next statement to
be run would actually attempt to be executed.
I suppose user agents can volunteer to remember this and
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
On Oct 16, 2007, at 4:04 PM, Geoffrey Garen 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
On 10/16/07, Geoffrey Garen [EMAIL PROTECTED] 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
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
On 10/15/07, Ian Hickson [EMAIL PROTECTED] wrote:
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
On Oct 15, 2007, at 2:07 PM, Ian Hickson wrote:
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
On Mon, 15 Oct 2007, Scott Hess wrote:
Under SQLite, there are cases where retrying might work, in which case
you can retry. There are other cases where retry will never work, you
need to rollback your transaction and start over. If you don't do so,
you can cause a deadlock. Much of
On Oct 15, 2007, at 8:37 PM, Ian Hickson wrote:
* CORRUPT, insofar as the Database API lets you delete databases
(it
doesn't currently, but we've thought of adding that to Gears).
You may be correct that authors shouldn't be dealing with this.
Guaranteeing the integrity of the database at
On 9/24/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 20 Sep 2007, Anne van Kesteren wrote:
The SQL API doesn't seem to define how to deal with errors, such as:
snip
* Database that is full
This currently just reports an error with code 1, like everything else,
but in due course we
On 10/5/07, Scott Hess [EMAIL PROTECTED] wrote:
In the first case, since we're working within the browser, there's
generally really nothing to be done, so most stuff falls to the second
case. At that point, it would be useful to have a human-readable
error string generated by the library
On Thu, 20 Sep 2007, Anne van Kesteren wrote:
The SQL API doesn't seem to define how to deal with errors, such as:
* Bogus SQL statements
Defined.
* SQL statements that are not supported for security reasons
Defined to be the same as bogus statements.
* SQL statements that are not
Hi,
The SQL API doesn't seem to define how to deal with errors, such as:
* Bogus SQL statements
* SQL statements that are not supported for security reasons
* SQL statements that are not supported because they don't make sense
* SQL statements that fail to return anything
* Database that
24 matches
Mail list logo
