[erlang-questions] Mnesia, disk_log and dets

Ulf Wiger ulf.wiger@REDACTED
Wed Feb 17 22:00:43 CET 2010

wde wrote:
> ok thank you.
> With Mnesiaex we can have our own storage backend for the  new
> "external_copies" type.
> But instead of specifying a new copy type, I'm currently trying to
> understand how I can integrate a wrapper module like
> "mnesia_disc_backend" that handle all disc access (for disc_copies
> and disc_only_copies) , and do the same thing for the "ram_copy"
> type, by using a "mnesia_ram_backend" module.
> The idea is to offer more flexibility and easily change the backend
> for ram and disc I/O.
> Do you think I'm wasting my time or that there is no interest for
> something like that ?

The external_copies concept originated in my rdbms contrib, so
it would be silly of me to deny that I at least at one time thought
this was a good idea. Two table types I experimented with at the
time was a log table and a read-only file system. I don't think that
mnesiaex copied the idea of hooking into the table creation operation
in mnesia_schema, which allowed the external copy callback to verify
custom table properties (such as mount point for the read-only file
system). One point of playing with these two tables was that I
wanted to experiment with types that had semantics that differed
significantly from those of sets and bags.

One thing to be very mindful of is that the callbacks for external
copies must be error-free. Any crash in these operations will cause
a mnesia core dump. This is the only sensible thing to do, as the
callback modules are called /after/ commit, i.e. the point of no
return as far as consistency is concerned.

Ulf W
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd



Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.


More information about the erlang-questions mailing list