What exactly do you mean by "own log of each transaction"? As I explained, I have a complex database with many tables and triggers. It will not be simple to implement undo the way it is explained in the wiki, and I suspect it will cost much in performance (but maybe I am wrong here...). If journals can be used the way I explained, this simplify the undo (because the database should not be changed at all), and also I suspect that the performance is not affected (apart from the fact that we have to store the journals somewhere). I am not sure about the size of the journals, and especially if they could be used at all after the transaction is committed.
On 11/19/06, John Stanton <[EMAIL PROTECTED]> wrote:
Ran wrote: > 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] >> >> ----------------------------------------------------------------------------- >> Why not maintain your own log of each transaction? Then you can undo and redo without limit. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
