Backtrackable Updates

storage_insert_keypair_bt(+StorageName, +Key, +Value, ?Inserted)

This predicate works exactly as its non-backtrackable counterpart, storage_insert_keypair/4, when the top-level goal succeeds. However, if the top-level goal fails, then the result of the insertion is undone. In other words, the pair remains in the database until it is explicitly deleted or until the top-level query fails. The exact semantics is defined by Transaction Logic [6].

Backtrackable key-value pairs are kept in the same database as non-backtrackable pairs and are queried through the same predicate keypair_find/2.

storage_delete_keypair_bt(+StorageName, +Key, ?Deleted)

Like storage_delete_keypair/3, but backtrackable.

storage_insert_fact_bt(+StorageName, +Goal)

Like storage_insert_fact/2, but backtrackable.

storage_delete_fact_bt(+StorageName, +Goal)

This is a backtrackable version of storage_delete_fact/2.

storage_reclaim_space(+StorageName)

This is similar to reclaim_space/1 for assert and retract, but it is used for storage managed by the primitives defined in the storage module. As with reclaim_space/1, this goal is typically called just before returning to the top level.