Prolog newbie interested in database ACID transactions (theory)

Discussion
1

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.

2

Are you referring to transactions section in manual, or something else?

3

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.

Nested transactions would have ‘relative’ cuts, which are relative to the particular
nesting level.

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.

4

There’s some work being done on using a persisten database that maps directly to Prolog facts and rules: Persistent predicates based on RocksDB

I plan on working on this, but I’ve been sidetracked with getting some prerequisite stuff working better (SWI-cpp.h, for example).

5

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.

6

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.

7

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.

8

The existing experimental 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 avoids most of their problems.

9

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.