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
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
If any of this sounds familiar to you, I’d love any links to papers, blogs, web sites,
that might be relevant.
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.
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.
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.