On Fri, Jan 14, 2011 at 8:55 PM, Pavel Ivanov <paiva...@gmail.com> wrote:
> > There are some challenges, for example to allow arbitrary undo > > operations we should also log transaction boundaries since undoing to > some > > points in between not only makes little sense, but also dangerous. But I > > think if implemented with those challenges solved, such implementation > would > > help to implement you "commit to save point'. > > Also you will have to re-write SQLite to make it distinguish between > different statements inside transaction, not cache changes from > different statements to the same database page in memory and transfer > all changed database pages to VFS after each statement, not in the end > of transaction... Sounds like a huge change... > > > Pavel, you seem to see this on a higher level, I simply thought about an implementation not knowing about sql at all. Imagine your base in different times, what's the difference between them regardless of the types of changes? It's just slightly different data at different positions. For restoring any previous state one will need only full log of writes (offset, length and data). Everying that is going to be overwritten can be tracked inside xWrite. Restoring to a point in the past is just writing this log backwards till the correct state (out of a transaction). One of the solution to logging transaction boundaries is to track header changes (the only place to know sqlite file format), i.e. there's a known last actions about writing some fields when the transaction ends. When xWrite filter detects this special write, it writes EndOfTransaction record to the log. The following undo operations limits restoring only to those states when this special record is reached. Max Vlasov _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
