<div dir="ltr"><div>Hi Jean-Sébastien,</div><div><br></div><div>Thank you so much for your awesome clear explanation.</div><div><br></div><div>>>> Triggers in Khepri could be compared to a combination between <br>
>>> `erlang:monitor/2` (which would know about tree nodes) and `erlang:apply/2`.</div><div>I feel more comfortable now knowing this comparison.</div><div><br></div><div>Thank You</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Pada tanggal Jum, 18 Feb 2022 pukul 23.04 Jean-Sébastien Pédron <<a href="mailto:jean-sebastien.pedron@dumbbell.fr">jean-sebastien.pedron@dumbbell.fr</a>> menulis:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 18/02/2022 15:36, I Gusti Ngurah Oka Prinarjaya wrote:<br>
> Triggers in an RDBMS database are a nightmare. I never use trigger in <br>
> MySQL / PostgreSQL / etc RDBMS.<br>
> I worried the trigger feature in Khepri will also become a nightmare. <br>
> Please reconsider adding a trigger feature.<br>
<br>
Thank you for your feedback! I should have explained the use case a bit <br>
more.<br>
<br>
Adding, updating or deleting something in the Khepri tree is represented <br>
as a Ra/Raft command. All members of a Khepri cluster are instances of a <br>
state machine. These state machines must apply commands to make progress <br>
with their state and they must all reach the same result given the same <br>
set of commands.<br>
<br>
Therefore, transactions in Khepri are not allowed to have side effects <br>
(send a message to an Erlang process, write something to the <br>
disk/network, etc.).<br>
<br>
However, sometimes we need those side effects. For instance in RabbitMQ, <br>
when a vhost, a queue, a binding, an internal user, ... is deleted, an <br>
internal event is emitted to notify other processes. This can't happen <br>
inside the transaction code.<br>
<br>
One possibility is for the code who requests the transaction to also <br>
emit that event once the transaction is complete. That's ok because it <br>
knows about what it is deleting.<br>
<br>
However, some tree nodes are deleted automatically because they were <br>
under another node higher in the tree. In this case, we need an <br>
automatic way to emit that event when these nodes are deleted as a <br>
consequence of something else. This is when triggers are useful.<br>
<br>
Here, triggers can't mess with the database content directly. They can <br>
request modifications, but like any caller in the end. Thus they would <br>
go through a Ra command too.<br>
<br>
Triggers in Khepri could be compared to a combination between <br>
`erlang:monitor/2` (which would know about tree nodes) and `erlang:apply/2`.<br>
<br>
Do you still see that as a source of problems?<br>
<br>
-- <br>
Jean-Sébastien Pédron<br>
</blockquote></div>