I think I didn't explain my question well enough. I know all what you wrote about transactions. The undo functionality I am looking for is over _several_ transactions.
I just wonder if it is possible to twist sqlite to keep the journals created during transactions (so to store them just before they are deleted when a commit is called). Then, when one wants to undo several transaction (each might include indeed many inserts/updates/deletes), those kept journals will help him to "rollback" several times to a former situation. So to implement undo by keeping journals. This will give undo functionality for practically any database (so the database design - the tables, triggers etc. will not have to be taken into account). I just wonder if it is possible/reasonable to implement that way undo functionality, and if not - why not. Ran On 11/19/06, Jay Sprenkle <[EMAIL PROTECTED]> wrote:
On 11/18/06, Ran <[EMAIL PROTECTED]> wrote: > The way the undo-redo is described in the wiki involves triggers to insert > the information of the change in each table to other table which logs the > changes. This will have a price in performance. It also complicates things > when triggers are already used for other things. > > So I wonder if journals might be used to implement undo: > If I understand it correctly, for each transaction there is journal that > keeps the information so the transaction could be rolled back. If the > journals are kept somewhere could they be used to rollback _successful_ > transactions? Transactions let you "undo" whatever you have done since the transaction started. You decide if it was "successful" or not and either commit the transaction to make it permanent or roll it back to undo it. In the case of large numbers of insertions it's faster to put them into a transaction and commit them than to do them separately. Performance in most installations is very quick since the database generally ends up in operating system cache. I do recall the author of mysql writing "he had no intention of implementing transaction since it was much slower and proper design eliminated the need for them." Sqlite has a much lower code overhead than mysql so I imagine it's just as fast or faster in most cases. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
