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

[Ulf Wiger]

On 20 Dec 2010, at 15:13, Dave Smith wrote:

> On Mon, Dec 20, 2010 at 6:56 AM, Ulf Wiger
> <ulf.wiger@REDACTED> wrote:
>> I think that conceptually, it would seem good to keep the
>> ram_copies, disc_copies and disc_only_copies, regardless of
>> back-end, since they address higher-level access characteristics
>> (e.g. TokyoCabinet is, strictly speaking, also disc_only.)
> 
> So are you describing a new parameter for "backend" or is that the
> intention of "external_copies"?

The 'external_copies' option was my first hack, but I think it was
the wrong way to go. It just becomes confusing to have a new 
type of copy type every time you introduce a new backend.
Why should I care as a user if my disc-only data is stored in 
InnoDB, BDB, dets, TC or something else?

>> A form of behaviour option could then be added that gives
>> additional options - e.g. tuning parameters to InnoDB, dets, ets,
>> or whatever back-end is being used.
>> 
>> Taking it one step further, it should be possible to specify a
>> default behaviour for each copy type, and override per-table.
> 
> +1 on all of this; mnesia gets a whole lotta more interesting/viable
> as a large-scale store when you can swap out the backend.
> 
> I do wonder, though, about the implications of transactions if you
> start using a non-transactional backend -- or does the existing
> transactional system take care of that?

Dets and ets are non-transactional. :)
The more complicated case if it's a transactional back-end, or if
the backend has implicit replication (which Joel Reymont had to 
deal with when he made an Amazon S3 backend for mnesia).

If the backend uses transaction semantics (e.g. the update can be
aborted), it cannot be plugged in at the same level as e.g. ets and
dets. That would rather require some transaction proxy, which 
supports one of mnesia's commit protocols.

That seems doable, but I'm sure there are complications I am 
overlooking.

BR,
Ulf W

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