<div dir="auto">Hi Jean-Sébastien,</div><div dir="auto"><br></div><div dir="auto">Very well done!!!</div><div dir="auto"><br></div><div dir="auto">Anything that can save me (+my team) from Mnesia is always welcome.</div><div dir="auto"><br></div><div dir="auto">Do you provide (throughput / latency) benchmarks?</div><div dir="auto"><br></div><div dir="auto">/F</div><div dir="auto"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><<a href="mailto:jean-sebastien.pedron@dumbbell.fr">jean-sebastien.pedron@dumbbell.fr</a>>  :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hi!<br>
<br>
On behalf of the RabbitMQ team, I'm pleased to announce Khepri 0.2.1! It <br>
is available on:<br>
     * GitHub (<a href="https://github.com/rabbitmq/khepri/releases/tag/v0.2.1" rel="noreferrer" target="_blank">https://github.com/rabbitmq/khepri/releases/tag/v0.2.1</a>)<br>
     * Hex.pm (<a href="https://hex.pm/packages/khepri" rel="noreferrer" target="_blank">https://hex.pm/packages/khepri</a>)<br>
<br>
Khepri is a tree-like replicated on-disk database library for Erlang and <br>
Elixir. This is a library we plan to use inside RabbitMQ as a <br>
replacement for Mnesia. Indeed, we want to leverage Ra[1], our <br>
implementation of the Raft consensus algorithm, to have a uniform <br>
behavior, especially w.r.t. network partitions, across all types of data <br>
managed by RabbitMQ.<br>
<br>
The release notes of 0.2.0 [2] describe the highlights of Khepri 0.2.x <br>
in detail, but I would like to quickly talk about the biggest one: <br>
triggers and stored procedures!<br>
<br>
Triggers are a mechanism to execute an anonymous function automatically <br>
following some events.<br>
<br>
Currently supported events are changes made to the tree: nodes were <br>
created, updated or deleted. In the future, it could support Erlang <br>
process monitoring, node monitoring, and so on. Triggers are registered <br>
using an event filter which, as its name suggests, takes care of <br>
filtering the event which should execute the associated function.<br>
<br>
The anonymous function behind a trigger is stored in the database as the <br>
payload of tree node. This function is called a stored procedure. Before <br>
it is stored, the function is extracted like transaction functions are. <br>
However, there are no restrictions on what it can do, unlike transaction <br>
functions.<br>
<br>
If you have any comments and feedback, or if you started to play with <br>
the library in one of your projects, please share! I’m looking forward <br>
to listen to your experience!<br>
<br>
Thank you very much!<br>
<br>
[1] <a href="https://github.com/rabbitmq/ra" rel="noreferrer" target="_blank">https://github.com/rabbitmq/ra</a><br>
[2] <a href="https://github.com/rabbitmq/khepri/releases/tag/v0.2.0" rel="noreferrer" target="_blank">https://github.com/rabbitmq/khepri/releases/tag/v0.2.0</a><br>
<br>
-- <br>
Jean-Sébastien Pédron<br>
</blockquote></div></div>