Hi,

there are some ideas for vfs implementation that would require tracking
file change counter. As I recall, I asked about specific api for working
with file change counter, and seems like there was no such. On the other
side it looks like it's not a problem since probably until db format change
significantly the location of this value in the file will stay unchanged.

One of the recent thought I had was implementing time machine vfs. So on
the developer level he opens the db either in general mode or history
(read-only) mode providing the date (or version) for working with the db as
it was in the past. Technically implementing such vfs should not be a
problem. For any file write (sector write) we save the prior contents of
the location together with offset-size and version information (file change
counter is good for this). The history mode instead of reading the main
data, uses the saved history data and searches for best fit to get
requested sector contents. But for correct work this vfs should rely on the
fact that file change counter will stay the same until the final write to
the first sector. And the bad thing here is that I should read this value
manually so some conflict with existing sqlite cache is possible. So can
vfs in this case work in sync with sqlite or it's too complicated?

Thanks,

Max
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to