Lambda the Ultimate

The database is written in Erlang, runs in the same OS process as the application, and stores Erlang terms natively (each row is a tuple). The data model is just like a hashtable or a tree, and because there is no latency you can just write your queries as straight Erlang code and give Mnesia a closure to execute with transaction semantics.

I think that Mnesia is one of the best programs in the world.

We use Mnesia for the configuration database in our system, and put a few hooks to good use. For one thing, the database itself notifies the appropriate processes when their configuration is changed. For another, we use a hook right before the end of each transaction to call our consistency-checker. If it finds an inconsistency, the database is transaction gets rolled back, so our "valid configuration" invariants are strongly enforced. (Can only be broken by redefining the invariants.)

Consistency rules are written either in straight Erlang or in a small DSL. The rules are always deterministic with respect to the configuration database, and we record precise dependency information for each of them to avoid rechecking properties that cannot have been broken.

When a rule specified with the DSL is broken, an explanation of the error is automatically generated from the rule text. I enjoy some local infamy for how very badly I wrote the text generator :-). This week a colleague showed me this gem:

Invalid setting for /cfg/ssl/server 1/ssl/cacerts.
Invalid because neither its value ([]) is not [] nor Verify (require) is not
require

What can I say? It looked so easy in Steele's thesis. That particular feature has been deprecated. :-)

About Mnesia: If I understand correctly, you connect to the DB using standard erlang message passing, right?

Can the DB live on a different machine (distributed app)? Can erlang closures go over the wire?

Our system is a line of clusterable internet appliances with a so-called "single system image". That is to say, each appliance runs Mnesia with full replication of the configuration of the whole cluster, and any configuration change is applied globally/atomically to all machines. If you have a lot of machines in the cluster, we nominate some as "masters" to participate in transactions, while the rest are "slaves" that just have the results of transactions pushed to them. If a slave needs to perform a transaction involving writes then it just sends the closure to its master via distribution.

So yes, closures go over the wire, but it requires you to have the same code on each machine (only a reference to the code is sent). This is the norm in Erlang clusters - they tend to be tightly coupled and have automated global/consistent software upgrades to keep them in sync.

If you really need to send a closure between two machines running different code, there is a fun trick. Probably they both have the same version of the Erlang interpreter (as used by the shell/REPL), so you can just pass a closure over its eval function that includes the syntax tree of the code-version-dependent expression you want to evaluate. (More practically, you can pull up a remote REPL via distribution, send the code you need over in a message, and patch it in.)

I haven't used it in anger myself, but I know some people that have and were quite happy with it.

I'll always have a fondness for Gemstone/S but GS/S never had a satisfactory solution to table integration. There are two ways I would have wanted to integrate ROE. One is that GS/S had its own special block syntax for structural access (PDF). This could have been ROE instead. The other is to have integrated ROE itself into GS/S for it's access to SQL databases.