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]
-----------------------------------------------------------------------------

Reply via email to