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. WAL should provide some of this, because over time the system should tend towards having everything stably written to the disk. You just have to think about how much you're willing to lose. Currently, there is a gray area where you've seen something which is incorrect, but you cannot reason about how extensive the damage is. Checksums can provide you with some ability to detect corruption more quickly, and perhaps a way to reason about it. You could have a function like iscorrupt(rowid) which could be used to salvage uncorrupted rows, and then carefully inspect corrupted rows. Or maybe you could delete the corrupt rows and then the table would be clean. Perhaps there could even be an ON CORRUPTION trigger involved. [Obviously, here I'm not thinking about the case where a DBA sits down and reconstructs things. I'm thinking about what you do when a database in the field has corruption. For instance, Chrome has a history database, and being able to easily delete corrupted rows and reconstruct indices would be an improvement over nuking the database from orbit. Without explicit database support, though, I've always been nervous about attempting such things in an ad-hoc fashion.] -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
