[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