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 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 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.
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.