This page documents a simple global non-contextual undo/redo mechanism.

## Mechanism

Database client keeps a global list of undoable/redoable operations. Operations are added to undo list during commit. Each commit creates a change set to server which defines the changes to resource values and statements. Change set also contains metadata for interpreting the change. The metadata format is defined by client and the server can not read or interpret it. Each operation has a unique change set identifier. Sequential operations are tagged as combined by giving them the same operation id. All operations with same id will be treated as single undoable/redoable operation.

### Combining write requests

Currently there is only one way to combine several database write requests into a single operation.

Normally an operation is created out of each separate write transaction. This happens when write transactions are initiated by invoking **Session.async/asyncRequest**. To combine a separate write transaction into a single operation, the write request must be initiated from within the write transaction using any **WriteGraph.async/asyncRequest** interface methods. The database client will group all write transaction change sets initiated like this into one operation.

## Undo and redo handling in the Simantics workbench

If **org.eclipse.ui.edit.undo** and **org.eclipse.ui.edit.redo** commands are bound to handlers **Session{Undo,Redo}Handler** then the undo/redo mechanism is activated. The handlers undo/redo one operation from the global undo/redo lists with each button press. It is desirable that each developer who develops requests that modify the graph comment their changes as shown by the following example.

~~~
    session.sync(new WriteRequest() {
        @Override
        public void perform(WriteGraph graph) throws DatabaseException {
            // Do your modifications.
            Layer0 b = Layer0.getInstance(graph);
            Resource s = graph.newResource();
            graph.claim(s, b.InstanceOf, b.Entity);

            // Add comment to change set.
            CommentMetadata cm = graph.getMetadata(CommentMetadata.class);
            cm.add("My comment.");
            graph.addMetadata(cm);
        }
    });
~~~

You can test your operations using the following procedure:

* Do the operation.
* Check from ''Teamwork'' / ''Graph History'' view which change sets have been created and that they are commented properly.

## Marking undo-points in database version history

Should the user simply perform write requests as described in [[#Undo and redo handling in the Simantics workbench]], each write request would simply create a new version into the database version history but all the changes would simply pile up into a single undoable operation.

The database API has two methods for telling the database that it's current persistent state should be regarded as an undo point and new undoable operation should be started. These are in interfaces <code>org.simantics.db.session</code> and <code>org.simantics.db.WriteOnlyGraph</code>:

~~~
public interface Session extends RequestProcessor {    
    ...
    /**
     * Marks the current database state or the beginning of the current ongoing
     * write transaction as an undo point. Calling this method several times
     * before or during the same write transaction has no effect.
     */
    void markUndoPoint();
    ...
}


public interface WriteOnlyGraph extends ServiceLocator, MetadataI {
    ...
    /**
     * Marks the beginning of the ongoing write transaction as an undo point.
     * Calling this method several times during the same transaction has no
     * effect.
     */
    void markUndoPoint();
    ...
}
~~~

## Related Documents

* TODO: consider: [[Undo and Redo]] - internals of the mechanism.