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 open is prohibitive
(you
may have to scan the entire database), and no guarantee in
practice, so
it's possible that you can detect corruption at any arbitrary
statement.
Sure, but that problem occurs everywhere. I mean, there's no JS
exception
for "your CPU core just overheated", but we don't guarentee that won't
happen either. Database corruption will occur either for hardware
reasons
or due to software bugs. Hardware failures could cause all kinds of
random
stuff, including software bugs (through corruption of executables).
Having
an API to handle software bugs seems silly, since if we could assume
that
that API was bug free, why not assume the rest of the API is too. This
just seems like a case we shouldn't worry about.
I agree with your principals here, but think databases are a different
story. 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 software can help avoid.
How the user agent handles the problem long term (ask the user what to
do, silently delete and recreate it, let the database continue to be
corrupt, etc) may not need to be specified, but 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.
Thanks,
~Brady
