> 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 On Fri, Jan 14, 2011 at 4:25 AM, Max Vlasov <max.vla...@gmail.com> wrote: > On Fri, Jan 14, 2011 at 2:16 AM, Charles Samuels <char...@cariden.com>wrote: > >> >> Here's more or less what I need: >> >> A * sqlite gets some inserts >> B * we're at a checkpoint, so everything after this point shouldn't get >> committed now. So "savepoint SP" >> C * insert some more into sqlite >> D * The checkpoint is ready to go, so we do "commit to savepoint SP" >> E * now, on-disk, the sqlite db contains everything in step A, but nothing >> in >> step C >> >> > If your design allows, you can move everything in C into one transaction > that either committed or rolled back depending on your condition in the > following steps. I assume you already considered this solution or I did not > get this right so possibly it's not an option. > > Some more complex solution. Recently I thought about implementing full or > partial undo with sqlite vfs. You probably know that sqlite works with the > file via virtual file system. If we forget about simulating access and > locking sqlite basically asks the vfs to read something at some offset and > write something at some offset. So if we take some file format that supports > multiply streams (microsoft compound for example), we can dedicate one > stream to sqlite native stream and another - for undo writings that is > basically just data blocks from the native stream before writing applied to > the corresponding file ranges. With unlimited space this should work as > unlimited undo, but even with limited space this will allow several steps > undo. 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'. > > Max Vlasov > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
