[erlang-questions] deprecate or rewrite mnesia:transaction/1

[Brentley Jones]

Having read Joe's latest book on Erlang, I didn't even know about mnesia:activity. I thought transaction was the only way to go. With that said, I think that transaction should be changed, because I'm pretty sure there are others out there like me that use it out of habit.

- Brentley Jones

On Nov 30, 2009, at 8:24 AM, Ulf Wiger wrote:

> 
> It has irked me for some time that everyone keeps using
> mnesia:transaction/1 instead of mnesia:activity/2.
> 
> The main problem with mnesia:transaction/1 is that it can't
> be extended by changing activity modules. This means e.g. that
> if you outgrow your disc_only tables, what would have been a
> fairly simple operation to switch to fragmented tables (adding
> an environment variable and making the necessary schema changes)
> suddenly becomes a rewrite.
> 
> The problem is that while mnesia:activity/2 and mnesia:transaction/1
> call the same internal function, mnesia:transaction/6, in the
> former case, the environment variable -mnesia access_module is
> checked, while in the latter case, the access module is hard-coded
> to mnesia.erl.
> 
> Would it be a terrible violation to change mnesia:transaction/1
> so that it also respects the access_module variable? I have come
> to regard it as a misdirected case of backward compatibility,
> or perhaps even an oversight that it doesn't already.
> 
> If there are strong reasons for keeping mnesia:transaction/1 as
> it is, I vote for having it deprecated in favour of mnesia:activity/2,
> or perhaps a shorter version:
> 
> atomic(F) -> transaction(F, _Args = [], _Retries = infinity,
>                         mnesia_monitor:get_env(access_module))
> 
> ...or something like that.
> 
> BR,
> Ulf W
> -- 
> Ulf Wiger
> CTO, Erlang Training & Consulting Ltd
> http://www.erlang-consulting.com
> 
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>