If you maintain a log of each transaction, perhaps in SQL or some
similar form, then you can create the inverse of that to undo or run it
again to redo. Each transaction can have its own registration ID.
I should anticipate that you would use some form of circular buffer to
make the process self maintaining.
If you application is not orthogonal then you will have a lot of
difficulty implementing an undo and might review the design accordingly.
Ran wrote:
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]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
