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

[I Gusti Ngurah Oka Prinarjaya]

Hi Jean-Sébastien,

Thank you so much for your awesome clear explanation.

>>> Triggers in Khepri could be compared to a combination between
>>> `erlang:monitor/2` (which would know about tree nodes) and
`erlang:apply/2`.
I feel more comfortable now knowing this comparison.

Thank You



Pada tanggal Jum, 18 Feb 2022 pukul 23.04 Jean-Sébastien Pédron <
jean-sebastien.pedron@REDACTED> menulis:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220218/d8158a4f/attachment.htm>