[ANN] Khepri 0.2.1 - A tree-like replicated on-disk database library

[Jean-Sébastien Pédron]

On 18/02/2022 15:36, I Gusti Ngurah Oka Prinarjaya wrote:
> Triggers in an RDBMS database are a nightmare. I never use trigger in 
> MySQL / PostgreSQL / etc RDBMS.
> I worried the trigger feature in Khepri will also become a nightmare. 
> Please reconsider adding a trigger feature.

Thank you for your feedback! I should have explained the use case a bit 
more.

Adding, updating or deleting something in the Khepri tree is represented 
as a Ra/Raft command. All members of a Khepri cluster are instances of a 
state machine. These state machines must apply commands to make progress 
with their state and they must all reach the same result given the same 
set of commands.

Therefore, transactions in Khepri are not allowed to have side effects 
(send a message to an Erlang process, write something to the 
disk/network, etc.).

However, sometimes we need those side effects. For instance in RabbitMQ, 
when a vhost, a queue, a binding, an internal user, ... is deleted, an 
internal event is emitted to notify other processes. This can't happen 
inside the transaction code.

One possibility is for the code who requests the transaction to also 
emit that event once the transaction is complete. That's ok because it 
knows about what it is deleting.

However, some tree nodes are deleted automatically because they were 
under another node higher in the tree. In this case, we need an 
automatic way to emit that event when these nodes are deleted as a 
consequence of something else. This is when triggers are useful.

Here, triggers can't mess with the database content directly. They can 
request modifications, but like any caller in the end. Thus they would 
go through a Ra command too.

Triggers in Khepri could be compared to a combination between 
`erlang:monitor/2` (which would know about tree nodes) and `erlang:apply/2`.

Do you still see that as a source of problems?

-- 
Jean-Sébastien Pédron