Transaction rules

[quoll]

Considering rules that can be run automatically with a transact, the idea is to register operations with a database, so that transactions on the database will cause these operations to trigger.

There are 2 possibilities to consider:

1. Operations that execute with every transaction.
2. Operations that execute when transactions match a particular pattern.

Every transaction

Transaction Functions

Datomic has transaction functions which are functions that appear in tx-data and operate on what is in the database. These return a series of transact operations: additions, deletions, and more transaction functions. This iterates until all of the remaining operations are additions and deletions only. They are unaware of the transaction context that they are being called in (i.e. they have no ability to see :db/add or :db/retract operations. Users have called for these, but they do not offer much in the way of rules support.

Post Transaction Functions

An alternative to Datomic-style transaction functions could be one that executes before a transaction returns. All data that has been added-to/removed-from the database will be available as the result of the transaction. These could append to the the add/remove log that the next function sees. This would work for rules, except that each function would need to do it's own testing for applicability and to schedule the next function to be run.

Pattern Matching Transactions

These would appear similar to Naga rules.

Rule Pattern

These will have the same structure as an Asami :where clause.

Rule Output

• Production patterns: Based on the heads of Naga rules, these will project bindings into triples, possibly generating new nodes as required. The resulting triples will be inserted as a part of the current transaction. Limited retractions are also available, especially for update operations.
• Functions: These will be functions registered with the database to be called with the bindings from the patterns.

The benefits of this approach are multiple:

• Rules can be directly appropriated from Naga. Even if the same rules aren't used, knowledge of their structure will inform users.
• Production patterns can be scanned for interdependencies of rules. This allows automated scheduling.
• Unlike Naga, triples in the current transaction can be analyzed for matching query patterns, thereby scheduling rules to be run. These can be tested for during the insertion phase, which means that the data being input need only be iterated over the single time. Once rules have been scheduled then tests for them can be removed, speeding up the subsequent insertions. This becomes much closer to classical RETE engines.

Considerations

Post transaction functions

• pro: can be implemented faster
• pro: less complexity
• con: significant programming effort on rules implementer
• con: lack of efficiency

Pattern matching transactions

• con: significant programming effort
• con: more complex design
• pro: easy to write rules
• pro: optimal efficiency

[egierach]

I tend to think in terms of use cases. Could you, even just in plain old english, provide some examples of rules that would work well in "post-transaction functions" vs "pattern matching transactions"?

I read the Datomic docs you linked to and I can't really imagine how I'd use their transaction functions in the real world either. The example they give is so braindead simple that it doesn't do a good job of illustrating the potential of the system.

For example, in Datomic's doc, they provide a function that unconditionally adds a tuple to the database. I suppose you could call that a rule, but it's not a very instructive one. How would I make it conditional on data already in the database? They also mentioned using it to coerce data into a user-defined shape, but gave no examples of how that would be possible.