6.13.2.2 Backtrackable Updates

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

A call to this predicate inserts a key pair into StorageName as does storage_insert_keypair/4, and the key-value pair may be queried via storage_find_keypair/3, just as with the non-backtrackable updates described above. In addition, the key-value pair can be removed from StorageName by explicit deletion. However, the key pair will be removed from StorageName upon failing over the insertion goal unless a commit is made to StorageName through the goal storage_commit(StorageName). The exact semantics is defined by Transaction Logic [6].

Note it is the update itself that is backtrackable, not the key-value pair. Hence, a key-pair may be (provisionally) inserted by a backtrackable update and deleted by a non-backtrackable update, or inserted by a non-backtrackable update and (provisionally) deleted by a backtrackable update. Of course, whether such a mixture makes sense would depend on a given application.

storage_delete_keypair_bt(+StorageName, +Key, ?Deleted)

Like storage_delete_keypair/3, but backtrackable as described for storage_insert_keypair_bt/4.

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_commit(+StorageName)

Commits to StorageName any backtrackable updates since the last commit, or since initialization if no commit has been made to StorageName. If StorageName does not exist, the predicate silently fails.