The logged information can be used to revert certain transactions that happened in the past. Reinsert deleted rows, remove imported data, reverse updates etc. See chapter [What is logged](https://github.com/pgMemento/pgMemento/wiki/What-is-logged) for the full list of reverse events. The procedure is called `pgmemento.revert_transaction`. It loops over each row that was affected by the given transaction. By joining against the [audit_tables_dependency](https://github.com/pgMemento/pgMemento/wiki/Audit_tables_dependency-VIEW) view it's possible to produce the correct revert order without violating foreign key constraints, even if they are set to `ON UPDATE CASCADE` or `ON DELETE CASCADE`. The `depth` value in the `audit_tables_dependency` view produces the correct order.

## Self-referencing tables

Until v0.4, pgMemento tried to revert operations in tables with self-references through an ordering of audit_ids. But, since this concept would only work if hierachies have the same order, the idea was dropped. Now, the ID from the `row_log` table is used. This allows for reverting operation against any hierarchies, but **ONLY** if non-cascading
foreign keys are used. Otherwise, the user has to write his own revert script and flip the audit_order.