I don't understand how to implement undo property of user-friendly connects utilizing a transactional database.

Similarly it is best the user has multilevel (infinite) undoing possibility because it is mentioned here within the answer. Designs that might help within this problem are Memento or Command.

However, utilizing a complex database including triggers, ever-growing sequence amounts, and uninvertable methods it's difficult to imagine how an undo action may work on different points than transaction limitations. Quite simply, undo to some extent once the transaction committed during the last time is only a rollback, but exactly how can you really return to different moments?

UPDATE (in line with the solutions to date): I don't always want the undo works once the modification has already been committed, I'd concentrate on a running application by having an open transaction. Whenever the consumer clicks save this means a commit, before save - throughout exactly the same transaction - the undo should work. I understand that using database like a persistent layer is simply an implementation detail and also the user shouldn't make use of it. But when we believe that "The thought of undo inside a database as well as in a GUI are essentially various thingsInch and we don't use undo having a database then your infinite undoing is simply a buzzword. I understand that "rollback is ... not really a user-undo".

Just how to implement a customer-level undo because of the "cascading down effects because of any change" within the same transaction?

The thought of undo inside a database as well as in a GUI are essentially various things the GUI will probably be just one user application, with lower levels of interaction along with other components a database is really a multi-user application where changes might have cascading down effects because of any change.

The one thing to complete is permit the user to apply the prior condition like a new transaction, which might work or else just do not have undos following a commit (much like no undos following a save, that is a choice in lots of programs).

Some (all?) DBMSs support savepoints, which permit partial rollbacks:

savepoint s1;
insert into mytable (id) values (1);
savepoint s2;
insert into mytable (id) values (2);
savepoint s3;
insert into mytable (id) values (3);
rollback to s2;

Within the above example, just the first place would remain, another two could have been un-tied.

I do not believe it is practical generally to try undo after commit, for the reasons why you gave* and most likely others. If it's crucial in some scenario then you'll have to build lots of code to get it done, and consider the results of triggers etc.

  • I do not use whatever trouble with ever-growing sequences though?

It's almost exactly the same like William's publish (that we really chosen up), however i try to indicate a bit more detailed, why it's neccessary to implement a person undo (versus. utilizing a database rollback).

It might be useful to understand much more about the application, however i think for any user(-friendly) Undo/Redo the database isn't the sufficient layer to implement the feature.

  1. The consumer really wants to undo those things he did, separate from if these result in no/one/more database transactions
  2. The consumer really wants to undo those things HE did (not anybody else's)

The database from the perspective is implementation detail, something, you utilize like a programmer for storing data. The rollback is really a type of undo that can help YOU by doing this, it isn't a person-undo. While using rollback means to involve the consumer in things he does not need to know about and doesn't understand (and does not need to), that is never advisable.

As William published, you'll need an implementation within the client or on server side included in a session, which tracks the steps of the items you define as user-transaction and has the capacity to undo these. If database transactions were made throughout individuals user transactions you'll need other db transactions to revoke these (if at all possible). Make certain to provide valuable feedback when the undo isn't feasible, which again means, explain it business-smart not database-smart.