On Wed, Apr 3, 2013 at 5:08 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 3 Apr 2013, at 10:52pm, Nico Williams <n...@cryptonector.com> wrote: >> As a user I prefer continuous saving + infinite undo. > > Undo is difficult with SQLite. For instance, to undo an UPDATE command you > need to know the original values of all the fields updated, which may be > different in different rows.
There are wiki pages on how to do this. You can use triggers (before update triggers get old values) to keep a history table(s), or you can code it in application logic. There's several pages written about this, including code. Another thing you can do is to always have time ranges in the keys, and the only currently live keys are ones whose start..end ranges encompass the current datetime. This is more intrusive, but it's quite convenient (you can even set rows to be "deleted" at specific times in the future by setting their end datetimes to something less than "infinity"). > One way to do it is to continue to write different files, possibly using the > backup API as mentioned upthread. The backup approach doesn't scale so well with file size. History doesn't scale well with history, but you can always prune history. > Another way is to keep a log of the SQLite commands issued. To undo you > simply start from a saved state and 'replay' all the commands up to the undo > point. Sure. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
