On Sat, Feb 4, 2012 at 3:51 PM, Alexey Pechnikov <[email protected]>wrote:
> It's very important but there are some questions about > http://www.sqlite.org/src/info/72b01a982a > Some times ago DRH wrote that checksum calculation don't slow down > SQLite significantly. > But can be this realized in current SQLite 3.x branch? When checksum > can help to restore > damaged pages/database? > Very interesting discussion ) As I long time fun of vfs system of sqlite I thought about implementing this as a vfs extension. At first it seemed that changing the format is a necessity. Although there's also another approach. This vfs can implement the checksum data as a separate file ({dbname}.chk) and work with existing format, so passing all read/write operation unchanged and changing only records of the chk file. There are two different scenarios - When the software that modified the db opens the db correctly (using this vfs) - When some other tool (not aware of this vfs) modified the contents of the db. In this case the vfs can track File change counter (the one at offset 24) and compare the one saves in chk file and the current one. The mismatch can produce a warning, i.e as a recommendation to rebuild checksum db (although don't know whether the vfs can report some existing error). The same effect can be if the chk file is missing. Max _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
