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
