# Prolog newbie interested in database ACID transactions (theory) **URL:** \ **Category:** Discussion\ **Created:** [September 9, 2022, 12:41pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759 "2022-09-09T12:41:33Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![lisper](https://avatars.discourse-cdn.com/v4/letter/l/43a26b/32.png) [@lisper](https://swi-prolog.discourse.group/u/lisper)\ **Post date:** [September 9, 2022, 12:41pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/1 "2022-09-09T12:41:33Z")
Newbie here. I’m interested in references to the integration of Prolog with database transactions (ACID), including atomicity, commits, rollbacks, etc. I’m also interested in crash consistency. Any good theoretical papers on this Prolog topic? Thx. A Lisper. ---
**Author:** ![brebs](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@brebs](https://swi-prolog.discourse.group/u/brebs)\ **Post date:** [September 9, 2022, 4:09pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/2 "2022-09-09T16:09:36Z")
Are you referring to [transactions section in manual](https://www.swi-prolog.org/pldoc/man?section=transactions), or something else? ---
**Author:** ![lisper](https://avatars.discourse-cdn.com/v4/letter/l/43a26b/32.png) [@lisper](https://swi-prolog.discourse.group/u/lisper)\ **Post date:** [September 9, 2022, 7:28pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/3 "2022-09-09T19:28:04Z")
Hi Brebs: Thanks for the link, but this model/API seems to bolt on DB transactions as an afterthought, and doesn’t seem to be completely integrated into the core language. At first glance, more-or-less-pure Prolog would seem to be a perfect match for a persistent database. At the start of a transaction, the information is gathered up, and when it is time to ‘commit’, Prolog does a ‘cut’. If the gathering up phase fails, then the transaction can unwind by returning to a previous set of bindings, or ‘roll back’ by running operations in reverse. Of course, certain low-level internal operations would have to be performed atomically to ensure crash (and parallel programming) consistency. > **[Cut (logic programming)](https://en.wikipedia.org/wiki/Cut_(logic_programming))** > > The cut, in Prolog, is a goal, written as !, which always succeeds, but cannot be backtracked. Cuts can be used to prevent unwanted backtracking, which could add unwanted solutions and/or space/time overhead to a query. > The cut should be used sparingly. While cuts can be inserted into codes containing errors, if a test is unnecessary because a cut has guaranteed that it is true, it is good practice to say so in a comment at the appropriate place. > Some programmers call the cut a controversial co... Nested transactions would have ‘relative’ cuts, which are relative to the particular nesting level. > **[Nested transaction](https://en.wikipedia.org/wiki/Nested_transaction)** > > A nested transaction is a database transaction that is started by an instruction within the scope of an already started transaction. > Nested transactions are implemented differently in different databases. However, they have in common that the changes are not made visible to any unrelated transactions until the outermost transaction has committed. This means that a commit in an inner transaction does not necessarily persist updates to the system. > In some databases, changes made by the nested tra... In other words, such a persistent Prolog user wouldn’t need to know much about databases – or ‘transactions’ – at all, other than that a ‘cut’ is more-or-less a relative ‘commit’. If any of this sounds familiar to you, I’d love any links to papers, blogs, web sites, that might be relevant. Thanks. ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [September 9, 2022, 10:10pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/4 "2022-09-09T22:10:59Z")
There’s some work being done on using a persisten database that maps directly to Prolog facts and rules: [Persistent predicates based on RocksDB](https://swi-prolog.discourse.group/t/persistent-predicates-based-on-rocksdb/5501) I plan on working on this, but I’ve been sidetracked with getting some prerequisite stuff working better (SWI-cpp.h, for example). ---
**Author:** ![lisper](https://avatars.discourse-cdn.com/v4/letter/l/43a26b/32.png) [@lisper](https://swi-prolog.discourse.group/u/lisper)\ **Post date:** [September 9, 2022, 10:35pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/5 "2022-09-09T22:35:54Z")
Thanks, Peter. I did notice that RocksDB project, and will look into it further. I initially dismissed RocksDB due to RocksDB being only a key-value DB instead of a more general relational DB, but perhaps I need to look more carefully. ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [September 10, 2022, 12:04am UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/6 "2022-09-10T00:04:21Z")
The RocksDB project creates secondary indexes using a separate set of keys. If that can be combined with SWI-Prolog’s built-in indexing, it would provide a nice persistent backing store (I would hope that it could transparently extend to multiple nodes), and could probably be extended with transaction/1. But it’d be a non-trivial amount of work. ---
**Author:** ![lisper](https://avatars.discourse-cdn.com/v4/letter/l/43a26b/32.png) [@lisper](https://swi-prolog.discourse.group/u/lisper)\ **Post date:** [September 10, 2022, 1:35pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/7 "2022-09-10T13:35:27Z")
Hi Peter: My first goal is simple, clean semantics, as this is primarily an academic exercise; high performance would presumably come much, much later. So a simple interface to a simple persistent DB would seem to be the first order of business. ---
**Author:** ![peter.ludemann](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/peter.ludemann/32/48_2.png) [@peter.ludemann](https://swi-prolog.discourse.group/u/peter.ludemann)\ **Post date:** [September 10, 2022, 7:53pm UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/8 "2022-09-10T19:53:02Z")
The existing experimental [rocks-predicates](https://github.com/JanWielemaker/rocks-predicates) already has a clean semantics to a persistent DB … the next steps (I think) are making it faster and scalable to multiple nodes, plus ensuring that it integrates cleanly with regular Prolog. I’ve had some unhappy experiences with OODBs (I can write a bit about this if you want); but I think that [rocks-predicates](https://github.com/JanWielemaker/rocks-predicates) avoids most of their problems. ---
**Author:** ![joeblog](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/joeblog/32/122_2.png) [@joeblog](https://swi-prolog.discourse.group/u/joeblog)\ **Post date:** [October 8, 2022, 10:41am UTC](https://swi-prolog.discourse.group/t/prolog-newbie-interested-in-database-acid-transactions-theory/5759/9 "2022-10-08T10:41:13Z")
> I’m interested in references to the integration of Prolog with database > transactions (ACID), including atomicity, commits, rollbacks, etc. Isn’t this more in the implementation than the language? For instance, it seems to be popularly thought “SQL is ACID”, whereas I’d argue that’s true for client-server implementations like Postgres and MySQL, but not for SQLite which is an interpreter unencumbered with all the overhead of a “proper” database. I much prefer Prolog to SQL as a high-level language, but I suspect Postgres has many man years of work at the software-hardware interface which won’t be easy to catch up with.