On Tue, Jul 13, 2010 at 10:03 PM, Scott Hess <sh...@google.com> wrote: > On Tue, Jul 13, 2010 at 8:24 PM, Simon Slavin <slav...@bigfraud.org> 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users