- From: Brady Eidson <beidson@apple.com>
- Date: Mon, 15 Oct 2007 22:23:42 -0700
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
Received on Monday, 15 October 2007 22:23:42 UTC