[erlang-questions] discussion: mnesia table-specific options

Ulf Wiger ulf.wiger@REDACTED
Mon Dec 20 20:16:20 CET 2010


On 20 Dec 2010, at 20:05, Anthony Molinaro wrote:

> 
> On Mon, Dec 20, 2010 at 11:57:00PM +0530, Kannan wrote:
>> When we have the option to decide on the backend data-store, we can only use
>> the very basic functionalities of those databases (put, get, delete,
>> initialization, recovery?). Only this way; we can preserve the purpose of
>> Erlang.
> 
> mnesiax I believe abstracted all the required functions into a behaviour
> here
> 
> http://code.google.com/p/mnesiaex/source/browse/trunk/mnesiaex/src/mnesia_ext.erl
> 
> Which is mostly what you describe, but includes things like update_counter/3

Hmm, this is perhaps the wrong place to discuss it, but I didn't see where
in the patches they catch the throw(not_implemented) calls in the behaviour
mods. If my memory serves, mnesia dumps core if there are exceptions in 
the low-level mnesia_lib accessor functions.

Granted, I didn't look very hard, and didn't try it out, so I may well have missed it.

Anyway, I agree with the idea of having a behaviour for custom storage plugins,
indeed, like Riak - although admittedly, a plugin for mnesia becomes significantly
more difficult to implement. :)

There's an added complication: if an alternative backend is used to allow 
drastically larger volumes of data to be stored in a mnesia table, the built-in
table synchronization logic will have to be revisited. That will be fun too, but
one step at a time...

BR,
Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com





More information about the erlang-questions mailing list