Yes, I completely agree. But a single "undoable event" generates multiple changes to the database (which might as well be done inside a single transaction). Thus one click on Undo results in multiple changes to undo the event (ie, undoing the entire event's transaction). This implies that somehow the undo log either:
- Tags multiple rows in the undo log as comprising a single event, or - Accumulates multiple queries into a single row in the undo log I really liked the elegance of using triggers to automatically create the undo log, but I don't see how to accomplish either of the above strategies (tagging a group of undo rows, or concatenating multiple undos into a single row) in that design without some manual legwork. So my question was whether there is some "COMMIT_COUNT()" SQL function or constant that represents "the number of committed transactions on this database", as then I could just stick that in the trigger query and insert it along with the undo query into the undo log as follows: CREATE TEMP TRIGGER _ex1_it AFTER INSERT ON ex1 BEGIN INSERT INTO undolog VALUES(NULL,COMMIT_COUNT(),'DELETE FROM ex1 WHERE rowid='||new.rowid); END; Then multiple INSERTs in a single transaction would generate multiple DELETEs in the undolog, all tagged with the same commit count. Later, I could look up the set of queries necessary to undo that transaction with: SELECT sql FROM undolog WHERE commitcount=XXX; The upshot is I could roll back one transaction at a time, all the way back to the beginning (or as far as the undo log goes). But lacking a COMMIT_COUNT() function, I might instead just create a simple table: CREATE TABLE commitcount(num) And then increment that at the start of each transaction: UPDATE commitcount SET num=(SELECT num FROM commitcount)+1; And then my trigger could be something like: CREATE TEMP TRIGGER _ex1_it AFTER INSERT ON ex1 BEGIN INSERT INTO undolog VALUES(NULL,(SELECT num FROM commitcount),'DELETE FROM ex1 WHERE rowid='||new.rowid); END; This'll do the same thing, but requires a subquery, an extra table, and manual incrementing of the commit count. Works, but is yucky. Another way might be to create a table that just keeps track of which range in the undolog corresponds to which distinct undoable event (aka transaction)... Perhaps a bit cleaner, but still not great. Anyway, I was just curious if the COMMIT_COUNT() function existed, because then it'd be really clean and easy. But it sounds it doesn't, and that's what I wanted to know. Thanks! -david D. Richard Hipp wrote: > On May 13, 2008, at 6:21 PM, David Barrett wrote: > >> True, but even an application would need to "undo" in transactions, >> I'd >> think. Like, if a user drags a widget from column A to B, it >> generates >> an INSERT in one column and a DELETE in another. Pressing Undo once >> would leave it in both columns, which is probably unexpected. >> > > And undo/redo mechanism typically groups actions together by user > input event. The application is typically event driven. It sits idle > waiting for a user event, such as a mouse click. That event might > trigger a cascade of related events, some of which involve database > changes. All database changes associated with that one event are > undone together. You know that you have reached the end of your event > cascade when the event loop goes idle again. > > For processing gestures (drags, and other inputs that involve multiple > events spread out over time) you acquire a lock or a "grab" at the > beginning of the gesture, hold it throughout the gesture, then release > it when the gesture completes. You do not finish the undo package > until the end of the gesture. So the complete rule for when you stop > one undoable entry and start a new one is: you are idle (no pending > events) and you are not holding a grab. > > D. Richard Hipp > [EMAIL PROTECTED] > > > > _______________________________________________ > 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