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 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. 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.

You are (rightly) reading very specifically into what I am saying, whereas what I'm trying to get at is still vague and general.

Let me take a step back and try to frame it at a higher level

- A page opens a valid database handle.
- Some script uses that database handle - successfully
- Some external event happens on the client machine - database corruption, the user deletes the database from the user agent's "database management mode", gamma rays corrupt a single bit on the disk, or whatever. This event renders the database unusable. - Some action is taken to reset the database so that it is usable - lets pretend the resolution is always recreating an empty database from scratch - The script knows something wrong happened - it has a completely 100% generic error on its query. But it is unaware of the nature of this event and its resolution. It decides to execute a new sql statement, and the value of this statement (from the script's perspective) is reliant on previously established values in the database. The statement coincidentally succeeds even with the new empty database.

For further argument, lets pretend the script is in an onunload handler and its writing some small piece of data out to the database before the user "quits". It has a lot of other data in memory client- side that it *thinks* is in the database, but really isn't anymore. It *could* write this data out, preserving a lot of important user state. But it doesn't know to do so.

One can certainly make the argument that if this were a native application saving data to disk, it would be prudent to verify its data on disk. But I think "raw filesystem" and "database" are different paradigms with different usage expectations. An error code along the lines of "your database was just reset" might fit the bill. This could be because of corruption, because the user agent database management was invoked and the database cleared, or a number of other reasons.

This is a requested split from code 1 - "The statement failed for reasons not covered by any other code."

~Brady


Reply via email to