On Tue, Jul 13, 2010 at 10:03 PM, Scott Hess <[email protected]> wrote: > On Tue, Jul 13, 2010 at 8:24 PM, Simon Slavin <[email protected]> wrote: >> It might be useful to figure out whether we're aiming for >> detection or correction. By 'correction' I don't mean recovery >> of all information, I mean restoring the database to some state >> it was in just after a COMMIT took effect. There's no point in >> implementing a detection system if the users consider "This >> database is corrupt" something worth complaining about. On the >> other hand, implementing a correction system may well slow down >> every write operation and perhaps '_open' too. It's not worth >> doing that if slowing down SQLite will decrease usability. > > The best case is a system where corruption cannot happen. Since > that's clearly impossible ... > > Second-best would be an ability to rollback to a priori valid state.
[Sigh, did not mean some whizzy technical term, there. Meant "a prior valid state."] -scott _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
