This is an old revision of the document!
Transaction
Not sure if this should be a section or a “feature” page.
Transactions act as *buffers* for operations on the project graph. Each transaction maintains a set of queues, where each queue holds a list of modifications to be applied to the graph.
Automatic Transaction Management
When any RGG method is executed, GroIMP automatically creates a transaction if one does not already exist. All subsequent graph modifications during that operation are pushed into the current transaction's queues.
Logging and Undo Functionality
All transactions are logged in a transaction cache, which allows the following:
- Undo — You can traverse the log in reverse to undo previous operations by reversing the transactions.
- Redo — Undone transactions can be reapplied, restoring the graph to its former state.
Redo Limitations
Once a new transaction is initiated (e.g. by):
- Running a new RGG function,
- Modifying an object through the attribute editor,
- Adding an object via the menu,
the previous redo history is discarded. That means GroIMP does not support branching histories like version control systems.
Example of an unsupported sequence:
- Undo → Apply new operation → Redo ❌
After a new operation is applied following an undo, the redo path is no longer available.
Log
Each operation on the project graph is performed through a transaction. These transactions are logged in a cache. It is possible to read through this log and apply the transaction in reverse enabling undo-ing the last modifications.