<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- mnesia</title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
<!--
function getWinHeight() {
var myHeight = 0;
if( typeof( window.innerHeight ) == 'number' ) {
//Non-IE
myHeight = window.innerHeight;
} else if( document.documentElement && ( document.documentElement.clientWidth ||
document.documentElement.clientHeight ) ) {
//IE 6+ in 'standards compliant mode'
myHeight = document.documentElement.clientHeight;
} else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
//IE 4 compatible
myHeight = document.body.clientHeight;
}
return myHeight;
}
function setscrollpos() {
var objf=document.getElementById('loadscrollpos');
document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
}
function addEvent(obj, evType, fn){
if (obj.addEventListener){
obj.addEventListener(evType, fn, true);
return true;
} else if (obj.attachEvent){
var r = obj.attachEvent("on"+evType, fn);
return r;
} else {
return false;
}
}
addEvent(window, 'load', setscrollpos);
//--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="users_guide.html">User's Guide</a><br><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/mnesia-4.7.1.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>Mnesia</strong><br><strong>Reference Manual</strong><br><small>Version 4.7.1</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Table of Contents</strong></small></p>
<ul class="flipMenu">
<li id="loadscrollpos" title="mnesia " expanded="true">mnesia<ul>
<li><a href="mnesia.html">
Top of manual page
</a></li>
<li title="abort-1"><a href="mnesia.html#abort-1">abort/1</a></li>
<li title="activate_checkpoint-1"><a href="mnesia.html#activate_checkpoint-1">activate_checkpoint/1</a></li>
<li title="activity-2"><a href="mnesia.html#activity-2">activity/2</a></li>
<li title="activity-4"><a href="mnesia.html#activity-4">activity/4</a></li>
<li title="add_table_copy-3"><a href="mnesia.html#add_table_copy-3">add_table_copy/3</a></li>
<li title="add_table_index-2"><a href="mnesia.html#add_table_index-2">add_table_index/2</a></li>
<li title="all_keys-1"><a href="mnesia.html#all_keys-1">all_keys/1</a></li>
<li title="async_dirty-2"><a href="mnesia.html#async_dirty-2">async_dirty/2</a></li>
<li title="backup-1"><a href="mnesia.html#backup-1">backup/1</a></li>
<li title="backup_checkpoint-2"><a href="mnesia.html#backup_checkpoint-2">backup_checkpoint/2</a></li>
<li title="change_config-2"><a href="mnesia.html#change_config-2">change_config/2</a></li>
<li title="change_table_access_mode-2"><a href="mnesia.html#change_table_access_mode-2">change_table_access_mode/2</a></li>
<li title="change_table_copy_type-3"><a href="mnesia.html#change_table_copy_type-3">change_table_copy_type/3</a></li>
<li title="change_table_load_order-2"><a href="mnesia.html#change_table_load_order-2">change_table_load_order/2</a></li>
<li title="change_table_majority-2"><a href="mnesia.html#change_table_majority-2">change_table_majority/2</a></li>
<li title="clear_table-1"><a href="mnesia.html#clear_table-1">clear_table/1</a></li>
<li title="create_schema-1"><a href="mnesia.html#create_schema-1">create_schema/1</a></li>
<li title="create_table-2"><a href="mnesia.html#create_table-2">create_table/2</a></li>
<li title="deactivate_checkpoint-1"><a href="mnesia.html#deactivate_checkpoint-1">deactivate_checkpoint/1</a></li>
<li title="del_table_copy-2"><a href="mnesia.html#del_table_copy-2">del_table_copy/2</a></li>
<li title="del_table_index-2"><a href="mnesia.html#del_table_index-2">del_table_index/2</a></li>
<li title="delete-1"><a href="mnesia.html#delete-1">delete/1</a></li>
<li title="delete-3"><a href="mnesia.html#delete-3">delete/3</a></li>
<li title="delete_object-1"><a href="mnesia.html#delete_object-1">delete_object/1</a></li>
<li title="delete_object-3"><a href="mnesia.html#delete_object-3">delete_object/3</a></li>
<li title="delete_schema-1"><a href="mnesia.html#delete_schema-1">delete_schema/1</a></li>
<li title="delete_table-1"><a href="mnesia.html#delete_table-1">delete_table/1</a></li>
<li title="dirty_all_keys-1"><a href="mnesia.html#dirty_all_keys-1">dirty_all_keys/1</a></li>
<li title="dirty_delete-1"><a href="mnesia.html#dirty_delete-1">dirty_delete/1</a></li>
<li title="dirty_delete-2"><a href="mnesia.html#dirty_delete-2">dirty_delete/2</a></li>
<li title="dirty_delete_object-1"><a href="mnesia.html#dirty_delete_object-1">dirty_delete_object/1</a></li>
<li title="dirty_delete_object-2"><a href="mnesia.html#dirty_delete_object-2">dirty_delete_object/2</a></li>
<li title="dirty_first-1"><a href="mnesia.html#dirty_first-1">dirty_first/1</a></li>
<li title="dirty_index_match_object-2"><a href="mnesia.html#dirty_index_match_object-2">dirty_index_match_object/2</a></li>
<li title="dirty_index_match_object-3"><a href="mnesia.html#dirty_index_match_object-3">dirty_index_match_object/3</a></li>
<li title="dirty_index_read-3"><a href="mnesia.html#dirty_index_read-3">dirty_index_read/3</a></li>
<li title="dirty_last-1"><a href="mnesia.html#dirty_last-1">dirty_last/1</a></li>
<li title="dirty_match_object-1"><a href="mnesia.html#dirty_match_object-1">dirty_match_object/1</a></li>
<li title="dirty_match_object-2"><a href="mnesia.html#dirty_match_object-2">dirty_match_object/2</a></li>
<li title="dirty_next-2"><a href="mnesia.html#dirty_next-2">dirty_next/2</a></li>
<li title="dirty_prev-2"><a href="mnesia.html#dirty_prev-2">dirty_prev/2</a></li>
<li title="dirty_read-1"><a href="mnesia.html#dirty_read-1">dirty_read/1</a></li>
<li title="dirty_read-2"><a href="mnesia.html#dirty_read-2">dirty_read/2</a></li>
<li title="dirty_select-2"><a href="mnesia.html#dirty_select-2">dirty_select/2</a></li>
<li title="dirty_slot-2"><a href="mnesia.html#dirty_slot-2">dirty_slot/2</a></li>
<li title="dirty_update_counter-2"><a href="mnesia.html#dirty_update_counter-2">dirty_update_counter/2</a></li>
<li title="dirty_update_counter-3"><a href="mnesia.html#dirty_update_counter-3">dirty_update_counter/3</a></li>
<li title="dirty_write-1"><a href="mnesia.html#dirty_write-1">dirty_write/1</a></li>
<li title="dirty_write-2"><a href="mnesia.html#dirty_write-2">dirty_write/2</a></li>
<li title="dump_log-0"><a href="mnesia.html#dump_log-0">dump_log/0</a></li>
<li title="dump_tables-1"><a href="mnesia.html#dump_tables-1">dump_tables/1</a></li>
<li title="dump_to_textfile-1"><a href="mnesia.html#dump_to_textfile-1">dump_to_textfile/1</a></li>
<li title="error_description-1"><a href="mnesia.html#error_description-1">error_description/1</a></li>
<li title="ets-2"><a href="mnesia.html#ets-2">ets/2</a></li>
<li title="first-1"><a href="mnesia.html#first-1">first/1</a></li>
<li title="foldl-3"><a href="mnesia.html#foldl-3">foldl/3</a></li>
<li title="foldr-3"><a href="mnesia.html#foldr-3">foldr/3</a></li>
<li title="force_load_table-1"><a href="mnesia.html#force_load_table-1">force_load_table/1</a></li>
<li title="index_match_object-2"><a href="mnesia.html#index_match_object-2">index_match_object/2</a></li>
<li title="index_match_object-4"><a href="mnesia.html#index_match_object-4">index_match_object/4</a></li>
<li title="index_read-3"><a href="mnesia.html#index_read-3">index_read/3</a></li>
<li title="info-0"><a href="mnesia.html#info-0">info/0</a></li>
<li title="install_fallback-1"><a href="mnesia.html#install_fallback-1">install_fallback/1</a></li>
<li title="install_fallback-1"><a href="mnesia.html#install_fallback-1">install_fallback/1</a></li>
<li title="install_fallback-2"><a href="mnesia.html#install_fallback-2">install_fallback/2</a></li>
<li title="is_transaction-0"><a href="mnesia.html#is_transaction-0">is_transaction/0</a></li>
<li title="last-1"><a href="mnesia.html#last-1">last/1</a></li>
<li title="load_textfile-1"><a href="mnesia.html#load_textfile-1">load_textfile/1</a></li>
<li title="lock-2"><a href="mnesia.html#lock-2">lock/2</a></li>
<li title="match_object-1"><a href="mnesia.html#match_object-1">match_object/1</a></li>
<li title="match_object-3"><a href="mnesia.html#match_object-3">match_object/3</a></li>
<li title="move_table_copy-3"><a href="mnesia.html#move_table_copy-3">move_table_copy/3</a></li>
<li title="next-2"><a href="mnesia.html#next-2">next/2</a></li>
<li title="prev-2"><a href="mnesia.html#prev-2">prev/2</a></li>
<li title="read-1"><a href="mnesia.html#read-1">read/1</a></li>
<li title="read-2"><a href="mnesia.html#read-2">read/2</a></li>
<li title="read-3"><a href="mnesia.html#read-3">read/3</a></li>
<li title="read_lock_table-1"><a href="mnesia.html#read_lock_table-1">read_lock_table/1</a></li>
<li title="report_event-1"><a href="mnesia.html#report_event-1">report_event/1</a></li>
<li title="restore-2"><a href="mnesia.html#restore-2">restore/2</a></li>
<li title="s_delete-1"><a href="mnesia.html#s_delete-1">s_delete/1</a></li>
<li title="s_delete_object-1"><a href="mnesia.html#s_delete_object-1">s_delete_object/1</a></li>
<li title="s_write-1"><a href="mnesia.html#s_write-1">s_write/1</a></li>
<li title="schema-0"><a href="mnesia.html#schema-0">schema/0</a></li>
<li title="schema-1"><a href="mnesia.html#schema-1">schema/1</a></li>
<li title="select-2"><a href="mnesia.html#select-2">select/2</a></li>
<li title="select-4"><a href="mnesia.html#select-4">select/4</a></li>
<li title="select-1"><a href="mnesia.html#select-1">select/1</a></li>
<li title="set_debug_level-1"><a href="mnesia.html#set_debug_level-1">set_debug_level/1</a></li>
<li title="set_master_nodes-1"><a href="mnesia.html#set_master_nodes-1">set_master_nodes/1</a></li>
<li title="set_master_nodes-2"><a href="mnesia.html#set_master_nodes-2">set_master_nodes/2</a></li>
<li title="snmp_close_table-1"><a href="mnesia.html#snmp_close_table-1">snmp_close_table/1</a></li>
<li title="snmp_get_mnesia_key-2"><a href="mnesia.html#snmp_get_mnesia_key-2">snmp_get_mnesia_key/2</a></li>
<li title="snmp_get_next_index-2"><a href="mnesia.html#snmp_get_next_index-2">snmp_get_next_index/2</a></li>
<li title="snmp_get_row-2"><a href="mnesia.html#snmp_get_row-2">snmp_get_row/2</a></li>
<li title="snmp_open_table-2"><a href="mnesia.html#snmp_open_table-2">snmp_open_table/2</a></li>
<li title="start-0"><a href="mnesia.html#start-0">start/0</a></li>
<li title="stop-0"><a href="mnesia.html#stop-0">stop/0</a></li>
<li title="subscribe-1"><a href="mnesia.html#subscribe-1">subscribe/1</a></li>
<li title="sync_dirty-2"><a href="mnesia.html#sync_dirty-2">sync_dirty/2</a></li>
<li title="sync_transaction-3"><a href="mnesia.html#sync_transaction-3">sync_transaction/3</a></li>
<li title="system_info-1"><a href="mnesia.html#system_info-1">system_info/1</a></li>
<li title="table-1"><a href="mnesia.html#table-1">table/1</a></li>
<li title="table_info-2"><a href="mnesia.html#table_info-2">table_info/2</a></li>
<li title="transaction-2"><a href="mnesia.html#transaction-2">transaction/2</a></li>
<li title="transform_table-4"><a href="mnesia.html#transform_table-4">transform_table/4</a></li>
<li title="transform_table-3"><a href="mnesia.html#transform_table-3">transform_table/3</a></li>
<li title="traverse_backup-4"><a href="mnesia.html#traverse_backup-4">traverse_backup/4</a></li>
<li title="uninstall_fallback-0"><a href="mnesia.html#uninstall_fallback-0">uninstall_fallback/0</a></li>
<li title="uninstall_fallback-1"><a href="mnesia.html#uninstall_fallback-1">uninstall_fallback/1</a></li>
<li title="unsubscribe-1"><a href="mnesia.html#unsubscribe-1">unsubscribe/1</a></li>
<li title="wait_for_tables-2"><a href="mnesia.html#wait_for_tables-2">wait_for_tables/2</a></li>
<li title="wread-1"><a href="mnesia.html#wread-1">wread/1</a></li>
<li title="write-1"><a href="mnesia.html#write-1">write/1</a></li>
<li title="write-3"><a href="mnesia.html#write-3">write/3</a></li>
<li title="write_lock_table-1"><a href="mnesia.html#write_lock_table-1">write_lock_table/1</a></li>
</ul>
</li>
<li id="no" title="mnesia_frag_hash " expanded="false">mnesia_frag_hash<ul>
<li><a href="mnesia_frag_hash.html">
Top of manual page
</a></li>
<li title="init_state-2"><a href="mnesia_frag_hash.html#init_state-2">init_state/2</a></li>
<li title="add_frag-1"><a href="mnesia_frag_hash.html#add_frag-1">add_frag/1</a></li>
<li title="del_frag-1"><a href="mnesia_frag_hash.html#del_frag-1">del_frag/1</a></li>
<li title="key_to_frag_number-2"><a href="mnesia_frag_hash.html#key_to_frag_number-2">key_to_frag_number/2</a></li>
<li title="match_spec_to_frag_numbers-2"><a href="mnesia_frag_hash.html#match_spec_to_frag_numbers-2">match_spec_to_frag_numbers/2</a></li>
</ul>
</li>
<li id="no" title="mnesia_registry " expanded="false">mnesia_registry<ul>
<li><a href="mnesia_registry.html">
Top of manual page
</a></li>
<li title="create_table-1"><a href="mnesia_registry.html#create_table-1">create_table/1</a></li>
<li title="create_table-2"><a href="mnesia_registry.html#create_table-2">create_table/2</a></li>
</ul>
</li>
</ul>
</div></div>
<div id="content">
<div class="innertube">
<!-- refpage --><center><h1>mnesia</h1></center>
<h3>MODULE</h3>
<div class="REFBODY">mnesia</div>
<h3>MODULE SUMMARY</h3>
<div class="REFBODY">A Distributed Telecommunications DBMS </div>
<h3>DESCRIPTION</h3>
<div class="REFBODY"><p>
<p><span class="code">Mnesia</span> is a distributed DataBase Management System (DBMS),
appropriate for telecommunications applications and other Erlang
applications which require continuous operation and exhibit soft
real-time properties.
</p>
<p>Listed below are some of the most important and attractive capabilities, Mnesia provides:
</p>
<ul>
<li>
<p>A relational/object hybrid data model which is
suitable for telecommunications applications.
</p>
</li>
<li>
<p>A specifically designed DBMS query language, QLC (as an add-on library).
</p>
</li>
<li>
<p>Persistence. Tables may be coherently kept on disc as
well as in main memory.
</p>
</li>
<li>
<p>Replication. Tables may be replicated at several nodes.
</p>
</li>
<li>
<p>Atomic transactions. A series of table manipulation
operations can be grouped into a single atomic
transaction.
</p>
</li>
<li>
<p>Location transparency. Programs can be written without
knowledge of the actual location of data.
</p>
</li>
<li>
<p>Extremely fast real time data searches.
</p>
</li>
<li>
<p>Schema manipulation routines. It is possible to
reconfigure the DBMS at runtime without stopping the
system.
</p>
</li>
</ul>
<p>This Reference Manual describes the Mnesia API. This includes
functions used to define and manipulate Mnesia tables.
</p>
<p>All functions documented in these pages can be used in any
combination with queries using the list comprehension notation. The
query notation is described in the QLC's man page.
</p>
<p>Data in Mnesia is organized as a set of tables. Each table
has a name which must be an atom. Each table is made up of
Erlang records. The user is responsible for the record
definitions. Each table also has a set of properties. Below
are some of the properties that are associated with each
table:
</p>
<ul>
<li>
<p><span class="code">type</span>. Each table can either have 'set',
'ordered_set' or 'bag' semantics. Note: currently 'ordered_set'
is not supported for 'disc_only_copies'. If a table is of type
'set' it means that each key leads to either one or zero
records. <br>
If a new item is inserted with the same key as
an existing record, the old record is overwritten. On the
other hand, if a table is of type 'bag', each key can map to
several records. However, all records in type bag tables are
unique, only the keys may be duplicated.
</p>
</li>
<li>
<p><span class="code">record_name</span>. All records stored in a table must
have the same name. You may say that the records must be
instances of the same record type.
</p>
</li>
<li>
<p><span class="code">ram_copies</span> A table can be replicated on a number
of Erlang nodes. The <span class="code">ram_copies</span> property specifies a
list of Erlang nodes where RAM copies are kept. These
copies can be dumped to disc at regular intervals. However,
updates to these copies are not written to disc on a
transaction basis.
</p>
</li>
<li>
<p><span class="code">disc_copies</span> The <span class="code">disc_copies</span> property
specifies a list of Erlang nodes where the table is kept in
RAM as well as on disc. All updates of the table are
performed on the actual table and are also logged to disc.
If a table is of type <span class="code">disc_copies</span> at a certain node,
it means that the entire table is resident in RAM memory as
well as on disc. Each transaction performed on the table is
appended to a LOG file as well as written into the RAM
table.
</p>
</li>
<li>
<p><span class="code">disc_only_copies</span> Some, or all, table replicas
can be kept on disc only. These replicas are considerably
slower than the RAM based replicas.
</p>
</li>
<li>
<p><span class="code">index</span> This is a list of attribute names, or
integers, which specify the tuple positions on which
Mnesia shall build and maintain an extra index table.
</p>
</li>
<li>
<p><span class="code">local_content</span> When an application requires
tables whose contents is local to each node,
<span class="code">local_content</span> tables may be used. The name of the
table is known to all Mnesia nodes, but its contents is
unique on each node. This means that access to such a table
must be done locally. Set the <span class="code">local_content</span> field to
<span class="code">true</span> if you want to enable the <span class="code">local_content</span>
behavior. The default is <span class="code">false</span>.
</p>
</li>
<li>
<p><span class="code">majority</span> This attribute can be either <span class="code">true</span> or
<span class="code">false</span> (default is <span class="code">false</span>). When <span class="code">true</span>, a majority
of the table replicas must be available for an update to succeed.
Majority checking can be enabled on tables with mission-critical data,
where it is vital to avoid inconsistencies due to network splits.
</p>
</li>
<li>
<p><span class="code">snmp</span> Each (set based) Mnesia table can be
automatically turned into an SNMP ordered table as well.
This property specifies the types of the SNMP keys.
</p>
</li>
<li>
<p><span class="code">attributes</span>. The names of the attributes for the
records that are inserted in the table.
</p>
</li>
</ul>
<p>See <span class="code">mnesia:create_table/2</span> about the complete set of
table properties and their details.
</p>
<p>This document uses a table of persons to illustrate various
examples. The following record definition is assumed:
</p>
<div class="example"><pre>
-record(person, {name,
age = 0,
address = unknown,
salary = 0,
children = []}),
</pre></div>
<p>The first attribute of the record is the primary key, or key
for short.
</p>
<p>The function descriptions are sorted in alphabetic order. <strong>Hint:</strong>
start to read about <span class="code">mnesia:create_table/2</span>,
<span class="code">mnesia:lock/2</span> and <span class="code">mnesia:activity/4</span> before you continue on
and learn about the rest.
</p>
<p>Writing or deleting in transaction context creates a local copy
of each modified record during the transaction. During iteration,
i.e. <span class="code">mnesia:fold[lr]/4</span> <span class="code">mnesia:next/2</span> <span class="code">mnesia:prev/2</span>
<span class="code">mnesia:snmp_get_next_index/2</span>, mnesia will compensate for
every written or deleted record, which may reduce the
performance. If possible avoid writing or deleting records in
the same transaction before iterating over the table.
</p>
</p></div>
<h3>EXPORTS</h3>
<p><a name="abort-1"><span class="bold_code">abort(Reason) -> transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>Makes the transaction silently
return the tuple <span class="code">{aborted, Reason}</span>.
The abortion of a Mnesia transaction means that
an exception will be thrown to an enclosing <span class="code">catch</span>.
Thus, the expression <span class="code">catch mnesia:abort(x)</span> does
not abort the transaction. </p>
</p></div>
<p><a name="activate_checkpoint-1"><span class="bold_code">activate_checkpoint(Args) -> {ok,Name,Nodes} | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>A checkpoint is a consistent view of the system.
A checkpoint can be activated on a set of tables.
This checkpoint can then be traversed and will
present a view of the system as it existed at the time when
the checkpoint was activated, even if the tables are being or have been
manipulated.
</p>
<p><span class="code">Args</span> is a list of the following tuples:
</p>
<ul>
<li>
<p><span class="code">{name,Name}</span>. <span class="code">Name</span> of checkpoint. Each
checkpoint must have a name which is unique to the
associated nodes. The name can be reused only once the
checkpoint has been deactivated. By default, a name
which is probably unique is generated.
</p>
</li>
<li>
<p><span class="code">{max,MaxTabs}</span>. <span class="code">MaxTabs</span> is a list of
tables that should be included in the checkpoint. The
default is []. For these tables, the redundancy will be
maximized and checkpoint information will be retained together
with all replicas. The checkpoint becomes more fault
tolerant if the tables have several replicas. When a new
replica is added by means of the schema manipulation
function <span class="code">mnesia:add_table_copy/3</span>, a retainer will
also be attached automatically.
</p>
</li>
<li>
<p><span class="code">{min,MinTabs}</span>. <span class="code">MinTabs</span> is a list of
tables that should be included in the checkpoint. The
default is []. For these tables, the redundancy will be
minimized and the checkpoint information will only be retained
with one replica, preferably on the local node.
</p>
</li>
<li>
<p><span class="code">{allow_remote,Bool}</span>. <span class="code">false</span> means that
all retainers must be local. The checkpoint cannot be
activated if a table does not reside locally.
<span class="code">true</span> allows retainers to be allocated on any
node. Default is set to <span class="code">true</span>.
</p>
</li>
<li>
<p><span class="code">{ram_overrides_dump,Bool}</span>. Only applicable
for <span class="code">ram_copies</span>. <span class="code">Bool</span> allows you to choose
to backup the table state as it is in RAM, or as it is on
disc. <span class="code">true</span> means that the latest committed
records in RAM should be included in the checkpoint.
These are the records that the application accesses.
<span class="code">false</span> means that the records dumped to DAT files
should be included in the checkpoint. These are the
records that will be loaded at startup. Default is
<span class="code">false</span>.
</p>
</li>
</ul>
<p>Returns <span class="code">{ok,Name,Nodes}</span> or <span class="code">{error,Reason}</span>.
<span class="code">Name</span> is the (possibly generated) name of the
checkpoint. <span class="code">Nodes</span> are the nodes that
are involved in the checkpoint. Only nodes that keep a
checkpoint retainer know about the checkpoint.
</p>
</p></div>
<p><a name="activity-2"><span class="bold_code">activity(AccessContext, Fun [, Args]) -> ResultOfFun | exit(Reason)</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:activity(AccessContext, Fun, Args, AccessMod)</span> where <span class="code">AccessMod</span> is the default
access callback module obtained by
<span class="code">mnesia:system_info(access_module)</span>. <span class="code">Args</span>
defaults to the empty list <span class="code">[]</span>.</p>
</p></div>
<p><a name="activity-4"><span class="bold_code">activity(AccessContext, Fun, Args, AccessMod) -> ResultOfFun | exit(Reason)</span></a><br></p>
<div class="REFBODY"><p>
<p>This function executes the functional object <span class="code">Fun</span>
with the arguments <span class="code">Args</span>.
</p>
<p>The code which executes inside the activity can
consist of a series of table manipulation functions, which is
performed in a <span class="code">AccessContext</span>. Currently, the following
access contexts are supported:
</p>
<dl>
<dt><strong><span class="code">transaction</span></strong></dt>
<dd>
<p>Short for <span class="code">{transaction, infinity}</span></p>
</dd>
<dt><strong><span class="code">{transaction, Retries}</span></strong></dt>
<dd>
<p>Invokes <span class="code">mnesia:transaction(Fun, Args, Retries)</span>. Note that the result from the <span class="code">Fun</span> is
returned if the transaction was successful (atomic),
otherwise the function exits with an abort reason.
</p>
</dd>
<dt><strong><span class="code">sync_transaction</span></strong></dt>
<dd>
<p>Short for <span class="code">{sync_transaction, infinity}</span></p>
</dd>
<dt><strong><span class="code">{sync_transaction, Retries}</span></strong></dt>
<dd>
<p>Invokes <span class="code">mnesia:sync_transaction(Fun, Args, Retries)</span>. Note that the result from the <span class="code">Fun</span> is
returned if the transaction was successful (atomic),
otherwise the function exits with an abort reason.
</p>
</dd>
<dt><strong><span class="code">async_dirty</span></strong></dt>
<dd>
<p>Invokes <span class="code">mnesia:async_dirty(Fun, Args)</span>.
</p>
</dd>
<dt><strong><span class="code">sync_dirty</span></strong></dt>
<dd>
<p>Invokes <span class="code">mnesia:sync_dirty(Fun, Args)</span>.
</p>
</dd>
<dt><strong><span class="code">ets</span></strong></dt>
<dd>
<p>Invokes <span class="code">mnesia:ets(Fun, Args)</span>.
</p>
</dd>
</dl>
<p>This function (<span class="code">mnesia:activity/4</span>) differs in an
important aspect from the <span class="code">mnesia:transaction</span>,
<span class="code">mnesia:sync_transaction</span>,
<span class="code">mnesia:async_dirty</span>, <span class="code">mnesia:sync_dirty</span> and
<span class="code">mnesia:ets</span> functions. The <span class="code">AccessMod</span> argument
is the name of a callback module which implements the
<span class="code">mnesia_access</span> behavior.
</p>
<p>Mnesia will forward calls to the following functions:
</p>
<ul>
<li>
<p>mnesia:lock/2 (read_lock_table/1, write_lock_table/1)</p>
</li>
<li>
<p>mnesia:write/3 (write/1, s_write/1)</p>
</li>
<li>
<p>mnesia:delete/3 (delete/1, s_delete/1)</p>
</li>
<li>
<p>mnesia:delete_object/3 (delete_object/1, s_delete_object/1)</p>
</li>
<li>
<p>mnesia:read/3 (read/1, wread/1)</p>
</li>
<li>
<p>mnesia:match_object/3 (match_object/1)</p>
</li>
<li>
<p>mnesia:all_keys/1</p>
</li>
<li>
<p>mnesia:first/1</p>
</li>
<li>
<p>mnesia:last/1</p>
</li>
<li>
<p>mnesia:prev/2</p>
</li>
<li>
<p>mnesia:next/2</p>
</li>
<li>
<p>mnesia:index_match_object/4 (index_match_object/2)</p>
</li>
<li>
<p>mnesia:index_read/3</p>
</li>
<li>
<p>mnesia:table_info/2</p>
</li>
</ul>
<p>to the corresponding:
</p>
<ul>
<li>
<p>AccessMod:lock(ActivityId, Opaque, LockItem, LockKind)</p>
</li>
<li>
<p>AccessMod:write(ActivityId, Opaque, Tab, Rec, LockKind)</p>
</li>
<li>
<p>AccessMod:delete(ActivityId, Opaque, Tab, Key, LockKind)</p>
</li>
<li>
<p>AccessMod:delete_object(ActivityId, Opaque, Tab, RecXS, LockKind)</p>
</li>
<li>
<p>AccessMod:read(ActivityId, Opaque, Tab, Key, LockKind)</p>
</li>
<li>
<p>AccessMod:match_object(ActivityId, Opaque, Tab, Pattern, LockKind)</p>
</li>
<li>
<p>AccessMod:all_keys(ActivityId, Opaque, Tab, LockKind)</p>
</li>
<li>
<p>AccessMod:first(ActivityId, Opaque, Tab)</p>
</li>
<li>
<p>AccessMod:last(ActivityId, Opaque, Tab)</p>
</li>
<li>
<p>AccessMod:prev(ActivityId, Opaque, Tab, Key)</p>
</li>
<li>
<p>AccessMod:next(ActivityId, Opaque, Tab, Key)</p>
</li>
<li>
<p>AccessMod:index_match_object(ActivityId, Opaque, Tab, Pattern, Attr, LockKind)</p>
</li>
<li>
<p>AccessMod:index_read(ActivityId, Opaque, Tab, SecondaryKey, Attr, LockKind)</p>
</li>
<li>
<p>AccessMod:table_info(ActivityId, Opaque, Tab, InfoItem)</p>
</li>
</ul>
<p>where <span class="code">ActivityId</span> is a record which represents the
identity of the enclosing Mnesia activity. The first field
(obtained with <span class="code">element(1, ActivityId)</span> contains an
atom which may be interpreted as the type of the activity:
<span class="code">'ets'</span>, <span class="code">'async_dirty'</span>, <span class="code">'sync_dirty'</span> or
<span class="code">'tid'</span>. <span class="code">'tid'</span> means that the activity is a
transaction. The structure of the rest of the identity
record is internal to Mnesia.
</p>
<p><span class="code">Opaque</span> is an opaque data structure which is internal
to Mnesia.</p>
</p></div>
<p><a name="add_table_copy-3"><span class="bold_code">add_table_copy(Tab, Node, Type) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>This function makes another copy of a table at the
node <span class="code">Node</span>. The <span class="code">Type</span> argument must be
either of the atoms <span class="code">ram_copies</span>, <span class="code">disc_copies</span>,
or
<span class="code">disc_only_copies</span>. For example, the following call
ensures that a disc replica of the <span class="code">person</span> table also
exists at node <span class="code">Node</span>.</p>
<div class="example"><pre>
mnesia:add_table_copy(person, Node, disc_copies)
</pre></div>
<p>This function can also be used to add a replica of the
table named <span class="code">schema</span>.</p>
</p></div>
<p><a name="add_table_index-2"><span class="bold_code">add_table_index(Tab, AttrName) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>Table indices can and should be used whenever the user
wants to frequently use some other field than the key field
to look up records. If this other field has an index
associated with it, these lookups can occur in constant time
and space. For example, if our application wishes to use
the age field of persons to efficiently find all person with
a specific age, it might be a good idea to have an index on
the age field. This can be accomplished with the following
call:</p>
<div class="example"><pre>
mnesia:add_table_index(person, age)
</pre></div>
<p>Indices do not come free, they occupy space which is
proportional to the size of the table. They also cause insertions
into the table to execute slightly slower. </p>
</p></div>
<p><a name="all_keys-1"><span class="bold_code">all_keys(Tab) -> KeyList | transaction abort</span></a><br></p>
<div class="REFBODY"><p>
<p>This function returns a list of all keys in the table
named <span class="code">Tab</span>. The semantics of this function is context
sensitive. See <span class="code">mnesia:activity/4</span> for more information. In
transaction context it acquires a read lock on the entire
table.</p>
</p></div>
<p><a name="async_dirty-2"><span class="bold_code">async_dirty(Fun, [, Args]) -> ResultOfFun | exit(Reason)</span></a><br></p>
<div class="REFBODY"><p>
<p>Call the <span class="code">Fun</span> in a context which is not protected
by a transaction. The Mnesia function calls performed in the
<span class="code">Fun</span> are mapped to the corresponding dirty
functions. This still involves logging, replication and
subscriptions, but there is no locking, local transaction
storage, or commit protocols involved. Checkpoint retainers
and indices are updated, but they will be updated dirty. As
for normal mnesia:dirty_* operations, the operations are
performed semi-asynchronously. See
<span class="code">mnesia:activity/4</span> and the Mnesia User's Guide for
more details.
</p>
<p>It is possible to manipulate the Mnesia tables without
using transactions. This has some serious disadvantages, but
is considerably faster since the transaction manager is not
involved and no locks are set. A dirty operation does,
however, guarantee a certain level of consistency and it is
not possible for the dirty operations to return garbled
records. All dirty operations provide location transparency
to the programmer and a program does not have to be aware of
the whereabouts of a certain table in order to function.
</p>
<p><strong>Note:</strong>It is more than 10 times more efficient to read records dirty
than within a transaction.
</p>
<p>Depending on the application, it may be a good idea to use
the dirty functions for certain operations. Almost all
Mnesia functions which can be called within transactions
have a dirty equivalent which is much more
efficient. However, it must be noted that it is possible for
the database to be left in an inconsistent state if dirty
operations are used to update it. Dirty operations should
only be used for performance reasons when it is absolutely
necessary. </p>
<p><strong>Note:</strong> Calling (nesting) a <span class="code">mnesia:[a]sync_dirty</span>
inside a transaction context will inherit the transaction semantics.
</p>
</p></div>
<p><a name="backup-1"><span class="bold_code">backup(Opaque [, BackupMod]) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>Activates a new checkpoint covering all Mnesia tables,
including the schema, with maximum degree of redundancy and
performs a backup using <span class="code">backup_checkpoint/2/3</span>. The
default value of the backup callback module <span class="code">BackupMod</span>
is obtained by <span class="code">mnesia:system_info(backup_module)</span>.</p>
</p></div>
<p><a name="backup_checkpoint-2"><span class="bold_code">backup_checkpoint(Name, Opaque [, BackupMod]) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>The tables are backed up to external media using the backup
module <span class="code">BackupMod</span>. Tables with the local contents
property is being backed up as they exist on the current
node. <span class="code">BackupMod</span> is the default backup callback
module obtained by
<span class="code">mnesia:system_info(backup_module)</span>. See the User's
Guide about the exact callback interface (the
<span class="code">mnesia_backup behavior</span>).</p>
</p></div>
<p><a name="change_config-2"><span class="bold_code">change_config(Config, Value) -> {error, Reason} | {ok, ReturnValue}</span></a><br></p>
<div class="REFBODY"><p>
<p>The <span class="code">Config</span> should be an atom of the following
configuration parameters: </p>
<dl>
<dt><strong><span class="code">extra_db_nodes</span></strong></dt>
<dd>
<p><span class="code">Value</span> is a list of nodes which Mnesia should try to connect to.
The <span class="code">ReturnValue</span> will be those nodes in
<span class="code">Value</span> that Mnesia are connected to.
<br>
Note: This function shall only be used to connect to newly started ram nodes
(N.D.R.S.N.) with an empty schema. If for example it is used after the network
have been partitioned it may lead to inconsistent tables.
<br>
Note: Mnesia may be connected to other nodes than those
returned in <span class="code">ReturnValue</span>.</p>
</dd>
<dt><strong><span class="code">dc_dump_limit</span></strong></dt>
<dd>
<p><span class="code">Value</span> is a number. See description in
<span class="code">Configuration Parameters</span> below.
The <span class="code">ReturnValue</span> is the new value. Note this configuration parameter
is not persistent, it will be lost when mnesia stopped.</p>
</dd>
</dl>
</p></div>
<p><a name="change_table_access_mode-2"><span class="bold_code">change_table_access_mode(Tab, AccessMode) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>The <span class="code">AcccessMode</span> is by default the atom
<span class="code">read_write</span> but it may also be set to the atom
<span class="code">read_only</span>. If the <span class="code">AccessMode</span> is set to
<span class="code">read_only</span>, it means that it is not possible to perform
updates to the table. At startup Mnesia always loads
<span class="code">read_only</span> tables locally regardless of when and if
Mnesia was terminated on other nodes.</p>
</p></div>
<p><a name="change_table_copy_type-3"><span class="bold_code">change_table_copy_type(Tab, Node, To) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>For example:</p>
<div class="example"><pre>
mnesia:change_table_copy_type(person, node(), disc_copies)
</pre></div>
<p>Transforms our <span class="code">person</span> table from a RAM table into
a disc based table at <span class="code">Node</span>.
</p>
<p>This function can also be used to change the storage type of
the table named <span class="code">schema</span>. The schema table can only
have <span class="code">ram_copies</span> or <span class="code">disc_copies</span> as the storage type. If the
storage type of the schema is <span class="code">ram_copies</span>, no other table
can be disc resident on that node.</p>
</p></div>
<p><a name="change_table_load_order-2"><span class="bold_code">change_table_load_order(Tab, LoadOrder) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>The <span class="code">LoadOrder</span> priority is by default <span class="code">0</span> (zero)
but may be set to any integer. The tables with the highest
<span class="code">LoadOrder</span> priority will be loaded first at startup.</p>
</p></div>
<p><a name="change_table_majority-2"><span class="bold_code">change_table_majority(Tab, Majority) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p><span class="code">Majority</span> must be a boolean; the default is <span class="code">false</span>.
When <span class="code">true</span>, a majority of the table's replicas must be available
for an update to succeed. When used on fragmented tables, <span class="code">Tab</span>
must be the name base table. Directly changing the majority setting on
individual fragments is not allowed.</p>
</p></div>
<p><a name="clear_table-1"><span class="bold_code">clear_table(Tab) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>Deletes all entries in the table <span class="code">Tab</span>.</p>
</p></div>
<p><a name="create_schema-1"><span class="bold_code">create_schema(DiscNodes) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>Creates a new database on disc. Various files are
created in the local Mnesia directory of each node. Note
that the directory must be unique for each node. Two nodes
may never share the same directory. If possible, use a local
disc device in order to improve performance.</p>
<p><span class="code">mnesia:create_schema/1</span> fails if any of the
Erlang nodes given as <span class="code">DiscNodes</span> are not alive, if
Mnesia is running on anyone of the nodes, or if anyone of
the nodes already has a schema. Use
<span class="code">mnesia:delete_schema/1</span> to get rid of old faulty
schemas.
</p>
<p><strong>Note:</strong> Only nodes with disc should be
included in <span class="code">DiscNodes</span>. Disc-less nodes, that is nodes
where all tables including the schema only resides in RAM,
may not be included.</p>
</p></div>
<p><a name="create_table-2"><span class="bold_code">create_table(Name, TabDef) -> {atomic, ok} | {aborted, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>This function creates a Mnesia table called <span class="code">Name</span>
according to the
argument <span class="code">TabDef</span>. This list must be a list of
<span class="code">{Item, Value}</span> tuples, where the following values are
allowed:</p>
<ul>
<li>
<p><span class="code">{access_mode, Atom}</span>. The access mode is by
default the atom <span class="code">read_write</span> but it may also be
set to the atom <span class="code">read_only</span>. If the
<span class="code">AccessMode</span> is set to <span class="code">read_only</span>, it means
that it is not possible to perform updates to the table.
</p>
<p>At startup Mnesia always loads <span class="code">read_only</span> tables
locally regardless of when and if Mnesia was terminated
on other nodes. This argument returns the access mode of
the table. The access mode may either be read_only or
read_write.
</p>
</li>
<li>
<p><span class="code">{attributes, AtomList}</span> a list of the
attribute names for the records that are supposed to
populate the table. The default value is <span class="code">[key, val]</span>. The table must have at least one extra
attribute in addition to the key.
</p>
<p>When accessing single attributes in a record, it is not
necessary, or even recommended, to hard code any
attribute names as atoms. Use the construct
<span class="code">record_info(fields, RecordName)</span> instead. It can be
used for records of type <span class="code">RecordName</span></p>
</li>
<li>
<p><span class="code">{disc_copies, Nodelist}</span>, where
<span class="code">Nodelist</span> is a list of the nodes where this table
is supposed to have disc copies. If a table replica is
of type <span class="code">disc_copies</span>, all write operations on this
particular replica of the table are written to disc as
well as to the RAM copy of the table.
</p>
<p>It is possible
to have a replicated table of type <span class="code">disc_copies</span>
on one node, and another type on another node. The
default value is <span class="code">[]</span></p>
</li>
<li>
<p><span class="code">{disc_only_copies, Nodelist}</span>, where
<span class="code">Nodelist</span> is a list of the nodes where this table
is supposed to have <span class="code">disc_only_copies</span>. A disc only
table replica is kept on disc only and unlike the other
replica types, the contents of the replica will not
reside in RAM. These replicas are considerably slower
than replicas held in RAM.
</p>
</li>
<li>
<p><span class="code">{index, Intlist}</span>, where
<span class="code">Intlist</span> is a list of attribute names (atoms) or
record fields for which Mnesia shall build and maintain
an extra index table. The <span class="code">qlc</span> query compiler may
or may not utilize any additional indices while
processing queries on a table.
</p>
</li>
<li>
<p><span class="code">{load_order, Integer}</span>. The load order
priority is by default <span class="code">0</span> (zero) but may be set to
any integer. The tables with the highest load order
priority will be loaded first at startup.
</p>
</li>
<li>
<p><span class="code">{majority, Flag}</span>, where <span class="code">Flag</span> must be a boolean.
If <span class="code">true</span>, any (non-dirty) update to the table will abort unless
a majority of the table's replicas are available for the commit.
When used on a fragmented table, all fragments will be given
the same majority setting.
</p>
</li>
<li>
<p><span class="code">{ram_copies, Nodelist}</span>, where
<span class="code">Nodelist</span> is a list of the nodes where this table
is supposed to have RAM copies. A table replica of type
<span class="code">ram_copies</span> is obviously not written to disc on a
per transaction basis. It is possible to dump
<span class="code">ram_copies</span> replicas to disc with the function
<span class="code">mnesia:dump_tables(Tabs)</span>. The default value for
this attribute is <span class="code">[node()]</span>.
</p>
</li>
<li>
<p><span class="code">{record_name, Name}</span>, where <span class="code">Name</span> must
be an atom. All records, stored in the table, must have
this name as the first element. It defaults to the same
name as the name of the table.
</p>
</li>
<li>
<p><span class="code">{snmp, SnmpStruct}</span>. See
<span class="code">mnesia:snmp_open_table/2</span> for a description of
<span class="code">SnmpStruct</span>. If this attribute is present in the
<span class="code">ArgList</span> to <span class="code">mnesia:create_table/2</span>, the
table is immediately accessible by means of the Simple
Network Management Protocol (SNMP). This means that
applications which use SNMP to manipulate and control
the system can be designed easily, since Mnesia provides
a direct mapping between the logical tables that make up
an SNMP control application and the physical data which
makes up a Mnesia table.
</p>
</li>
<li>
<p><span class="code">{storage_properties, [{Backend, Properties}]</span>.
Forwards additional properties to the backend storage.
<span class="code">Backend</span> can currently be <span class="code">ets</span> or <span class="code">dets</span> and
<span class="code">Properties</span> is a list of options sent to the backend storage
during table creation. <span class="code">Properties</span> may not contain properties
already used by mnesia such as <span class="code">type</span> or <span class="code">named_table</span>.
</p>
<p>For example:</p>
<div class="example"><pre>
mnesia:create_table(table, [{ram_copies, [node()]}, {disc_only_copies, nodes()},
{storage_properties,
[{ets, [compressed]}, {dets, [{auto_save, 5000}]} ]}])
</pre></div>
</li>
<li>
<p><span class="code">{type, Type}</span>, where <span class="code">Type</span> must be
either of the atoms <span class="code">set</span>, <span class="code">ordered_set</span> or
<span class="code">bag</span>. The default value is <span class="code">set</span>. In a
<span class="code">set</span> all records have unique keys and in a
<span class="code">bag</span> several records may have the same key, but
the record content is unique. If a non-unique record is
stored the old, conflicting record(s) will simply be
overwritten. Note: currently 'ordered_set'
is not supported for 'disc_only_copies'.
</p>
</li>
<li>
<p><span class="code">{local_content, Bool}</span>, where <span class="code">Bool</span> must be
either <span class="code">true</span> or <span class="code">false</span>. The default value is <span class="code">false</span>.</p>
</li>
</ul>
<p>For example, the following call creates the <span class="code">person</span> table
previously defined and replicates it on 2 nodes:
</p>
<div class="example"><pre>
mnesia:create_table(person,
[{ram_copies, [N1, N2]},
{attributes, record_info(fields,person)}]).
</pre></div>
<p>If it was required that Mnesia build and maintain an extra index
table on the <span class="code">address</span> attribute of all the <span class="code">person</span>
records that are inserted in the table, the following code would be issued:
</p>
<div class="example"><pre>
mnesia:create_table(person,
[{ram_copies, [N1, N2]},
{index, [address]},
{attributes, record_info(fields,person)}]).
</pre></div>
<p>The specification of <span class="code">index</span> and <span class="code">attributes</span> may be
hard coded as <span class="code">{index, [2]}</span> and
<span class="code">{attributes, [name, age, address, salary, children]}</span>
respectively.
</p>
<p><span class="code">mnesia:create_table/2</span> writes records into the
<span class="code">schema</span> table. This function, as well as all other
schema manipulation functions, are implemented with the
normal transaction management system. This guarantees that
schema updates are performed on all nodes in an atomic
manner.</p>
</p></div>
<p><a name="deactivate_checkpoint-1"><span class="bold_code">deactivate_checkpoint(Name) -> ok | {error, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>The checkpoint is automatically deactivated when some of
the tables involved have no retainer attached to them. This may
happen when nodes go down or when a replica is deleted.
Checkpoints will also be deactivated with this function.
<span class="code">Name</span> is the name of an active checkpoint.</p>
</p></div>
<p><a name="del_table_copy-2"><span class="bold_code">del_table_copy(Tab, Node) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>Deletes the replica of table <span class="code">Tab</span> at node <span class="code">Node</span>.
When the last replica is deleted with this
function, the table disappears entirely.
</p>
<p>This function may also be used to delete a replica of
the table named <span class="code">schema</span>. Then the mnesia node will be removed.
Note: Mnesia must be stopped on the node first.</p>
</p></div>
<p><a name="del_table_index-2"><span class="bold_code">del_table_index(Tab, AttrName) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>This function deletes the index on attribute with name
<span class="code">AttrName</span> in a table.</p>
</p></div>
<p><a name="delete-1"><span class="bold_code">delete({Tab, Key}) -> transaction abort | ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:delete(Tab, Key, write)</span></p>
</p></div>
<p><a name="delete-3"><span class="bold_code">delete(Tab, Key, LockKind) -> transaction abort | ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Deletes all records in table <span class="code">Tab</span> with the key
<span class="code">Key</span>.
</p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires a lock of type <span class="code">LockKind</span> in the
record. Currently the lock types <span class="code">write</span> and
<span class="code">sticky_write</span> are supported.</p>
</p></div>
<p><a name="delete_object-1"><span class="bold_code">delete_object(Record) -> transaction abort | ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:delete_object(Tab, Record, write)</span> where
<span class="code">Tab</span> is <span class="code">element(1, Record)</span>.</p>
</p></div>
<p><a name="delete_object-3"><span class="bold_code">delete_object(Tab, Record, LockKind) -> transaction abort | ok </span></a><br></p>
<div class="REFBODY"><p>
<p>If a table is of type <span class="code">bag</span>, we may sometimes
want to delete only some of the records with a certain
key. This can be done with the <span class="code">delete_object/3</span>
function. A complete record must be supplied to this
function.
</p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires a lock of type <span class="code">LockKind</span> on the
record. Currently the lock types <span class="code">write</span> and
<span class="code">sticky_write</span> are supported.</p>
</p></div>
<p><a name="delete_schema-1"><span class="bold_code">delete_schema(DiscNodes) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>Deletes a database created with
<span class="code">mnesia:create_schema/1</span>.
<span class="code">mnesia:delete_schema/1</span> fails if any of the Erlang
nodes given as <span class="code">DiscNodes</span> is not alive, or if Mnesia
is running on any of the nodes.
</p>
<p>After the database has been deleted, it may still be
possible to start Mnesia as a disc-less node. This depends on
how the configuration parameter <span class="code">schema_location</span> is set.
</p>
<div class="warning">
<div class="label">Warning</div>
<div class="content"><p>
<p>This function must be used with extreme
caution since it makes existing persistent data
obsolete. Think twice before using it. </p>
</p></div>
</div>
</p></div>
<p><a name="delete_table-1"><span class="bold_code">delete_table(Tab) -> {aborted, Reason} | {atomic, ok} </span></a><br></p>
<div class="REFBODY"><p>
<p>Permanently deletes all replicas of table <span class="code">Tab</span>.</p>
</p></div>
<p><a name="dirty_all_keys-1"><span class="bold_code">dirty_all_keys(Tab) -> KeyList | exit({aborted, Reason}).</span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:all_keys/1</span> function.</p>
</p></div>
<p><a name="dirty_delete-1"><span class="bold_code">dirty_delete({Tab, Key}) -> ok | exit({aborted, Reason}) </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:dirty_delete(Tab, Key)</span>.</p>
</p></div>
<p><a name="dirty_delete-2"><span class="bold_code">dirty_delete(Tab, Key) -> ok | exit({aborted, Reason}) </span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:delete/3</span> function.</p>
</p></div>
<p><a name="dirty_delete_object-1"><span class="bold_code">dirty_delete_object(Record) </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:dirty_delete_object(Tab, Record)</span>
where <span class="code">Tab</span> is <span class="code">element(1, Record)</span>.</p>
</p></div>
<p><a name="dirty_delete_object-2"><span class="bold_code">dirty_delete_object(Tab, Record) </span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:delete_object/3</span> function.</p>
</p></div>
<p><a name="dirty_first-1"><span class="bold_code">dirty_first(Tab) -> Key | exit({aborted, Reason}) </span></a><br></p>
<div class="REFBODY"><p>
<p>Records in <span class="code">set</span> or <span class="code">bag</span> tables are not ordered.
However, there
is an ordering of the records which is not known
to the user. Accordingly, it is possible to traverse a table by means
of this function in conjunction with the <span class="code">mnesia:dirty_next/2</span>
function.
</p>
<p>If there are no records at all in the table, this function
returns the atom <span class="code">'$end_of_table'</span>. For this reason, it
is highly undesirable, but not disallowed, to use this atom
as the key for any user records.</p>
</p></div>
<p><a name="dirty_index_match_object-2"><span class="bold_code">dirty_index_match_object(Pattern, Pos)</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:dirty_index_match_object(Tab, Pattern, Pos)</span> where <span class="code">Tab</span> is <span class="code">element(1, Pattern)</span>.</p>
</p></div>
<p><a name="dirty_index_match_object-3"><span class="bold_code">dirty_index_match_object(Tab, Pattern, Pos)</span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:index_match_object/4</span> function.</p>
</p></div>
<p><a name="dirty_index_read-3"><span class="bold_code">dirty_index_read(Tab, SecondaryKey, Pos)</span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:index_read/3</span> function.</p>
</p></div>
<p><a name="dirty_last-1"><span class="bold_code">dirty_last(Tab) -> Key | exit({aborted, Reason}) </span></a><br></p>
<div class="REFBODY"><p>
<p>This function works exactly like
<span class="code">mnesia:dirty_first/1</span> but returns the last object in
Erlang term order for the <span class="code">ordered_set</span> table type. For
all other table types, <span class="code">mnesia:dirty_first/1</span> and
<span class="code">mnesia:dirty_last/1</span> are synonyms.</p>
</p></div>
<p><a name="dirty_match_object-1"><span class="bold_code">dirty_match_object(Pattern) -> RecordList | exit({aborted, Reason}).</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:dirty_match_object(Tab, Pattern)</span>
where <span class="code">Tab</span> is <span class="code">element(1, Pattern)</span>.</p>
</p></div>
<p><a name="dirty_match_object-2"><span class="bold_code">dirty_match_object(Tab, Pattern) -> RecordList | exit({aborted, Reason}).</span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:match_object/3</span> function.</p>
</p></div>
<p><a name="dirty_next-2"><span class="bold_code">dirty_next(Tab, Key) -> Key | exit({aborted, Reason}) </span></a><br></p>
<div class="REFBODY"><p>
<p>This function makes it possible to traverse a table
and perform operations on all records in the table. When
the end of the table is reached, the special key
<span class="code">'$end_of_table'</span> is returned. Otherwise, the function
returns a key which can be used to read the actual record.The
behavior is undefined if another Erlang process performs write
operations on the table while it is being traversed with the
<span class="code">mnesia:dirty_next/2</span> function.</p>
</p></div>
<p><a name="dirty_prev-2"><span class="bold_code">dirty_prev(Tab, Key) -> Key | exit({aborted, Reason}) </span></a><br></p>
<div class="REFBODY"><p>
<p>This function works exactly like
<span class="code">mnesia:dirty_next/2</span> but returns the previous object in
Erlang term order for the ordered_set table type. For
all other table types, <span class="code">mnesia:dirty_next/2</span> and
<span class="code">mnesia:dirty_prev/2</span> are synonyms.</p>
</p></div>
<p><a name="dirty_read-1"><span class="bold_code">dirty_read({Tab, Key}) -> ValueList | exit({aborted, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:dirty_read(Tab, Key)</span>.</p>
</p></div>
<p><a name="dirty_read-2"><span class="bold_code">dirty_read(Tab, Key) -> ValueList | exit({aborted, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:read/3</span> function.</p>
</p></div>
<p><a name="dirty_select-2"><span class="bold_code">dirty_select(Tab, MatchSpec) -> ValueList | exit({aborted, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of the
<span class="code">mnesia:select/2</span> function.</p>
</p></div>
<p><a name="dirty_slot-2"><span class="bold_code">dirty_slot(Tab, Slot) -> RecordList | exit({aborted, Reason})</span></a><br></p>
<div class="REFBODY"><p>
<p>This function can be used to traverse a table in a
manner similar to the <span class="code">mnesia:dirty_next/2</span> function.
A table has a number of slots which range from 0 (zero) to some
unknown upper bound. The function
<span class="code">mnesia:dirty_slot/2</span> returns the special atom
<span class="code">'$end_of_table'</span> when the end of the table is reached.
The behavior of this function is undefined if a write
operation is performed on the table while it is being
traversed.</p>
</p></div>
<p><a name="dirty_update_counter-2"><span class="bold_code">dirty_update_counter({Tab, Key}, Incr) -> NewVal | exit({aborted, Reason})</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:dirty_update_counter(Tab, Key, Incr)</span>.</p>
</p></div>
<p><a name="dirty_update_counter-3"><span class="bold_code">dirty_update_counter(Tab, Key, Incr) -> NewVal | exit({aborted, Reason})</span></a><br></p>
<div class="REFBODY"><p>
<p>There are no special counter records in Mnesia. However,
records of the form <span class="code">{Tab, Key, Integer}</span> can be used
as (possibly disc resident) counters, when <span class="code">Tab</span> is a
<span class="code">set</span>. This function updates a counter with a
positive or negative number. However, counters can never become less
than zero. There are two significant differences between
this function and the action of first reading the record,
performing the arithmetics, and then writing the record:</p>
<ul>
<li>It is much more efficient</li>
<li>
<span class="code">mnesia:dirty_update_counter/3</span> is
performed as an atomic operation despite the fact that it is not
protected by a transaction.</li>
</ul>
<p>If two processes perform <span class="code">mnesia:dirty_update_counter/3</span>
simultaneously, both updates will take effect without the
risk of losing one of the updates. The new value
<span class="code">NewVal</span> of the counter is returned.</p>
<p>If <span class="code">Key</span> don't exits, a new record is created with the value
<span class="code">Incr</span> if it is larger than 0, otherwise it is set to 0.</p>
</p></div>
<p><a name="dirty_write-1"><span class="bold_code">dirty_write(Record) -> ok | exit({aborted, Reason})</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:dirty_write(Tab, Record)</span>
where <span class="code">Tab</span> is <span class="code">element(1, Record)</span>.</p>
</p></div>
<p><a name="dirty_write-2"><span class="bold_code">dirty_write(Tab, Record) -> ok | exit({aborted, Reason})</span></a><br></p>
<div class="REFBODY"><p>
<p>This is the dirty equivalent of <span class="code">mnesia:write/3</span>.</p>
</p></div>
<p><a name="dump_log-0"><span class="bold_code">dump_log() -> dumped</span></a><br></p>
<div class="REFBODY"><p>
<p>Performs a user initiated dump of the local log file.
This is usually not necessary since Mnesia, by default,
manages this automatically.</p>
</p></div>
<p><a name="dump_tables-1"><span class="bold_code">dump_tables(TabList) -> {atomic, ok} | {aborted, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>This function dumps a set of <span class="code">ram_copies</span> tables
to disc. The next time the system is started, these tables
are initiated with the data found in the files that are the
result of this dump. None of the tables may have disc
resident replicas.</p>
</p></div>
<p><a name="dump_to_textfile-1"><span class="bold_code">dump_to_textfile(Filename) </span></a><br></p>
<div class="REFBODY"><p>
<p>Dumps all local tables of a mnesia system into a text file
which can then be edited (by means of a normal text editor)
and then later be reloaded with
<span class="code">mnesia:load_textfile/1</span>. Only use this function for
educational purposes. Use other functions to deal with real
backups.</p>
</p></div>
<p><a name="error_description-1"><span class="bold_code">error_description(Error) -> String </span></a><br></p>
<div class="REFBODY"><p>
<p>All Mnesia transactions, including all the schema
update functions, either return the value <span class="code">{atomic, Val}</span> or the tuple <span class="code">{aborted, Reason}</span>. The
<span class="code">Reason</span> can be either of the following atoms. The
<span class="code">error_description/1</span> function returns a descriptive
string which describes the error.
</p>
<ul>
<li>
<p><span class="code">nested_transaction</span>. Nested transactions are
not allowed in this context.
</p>
</li>
<li>
<p><span class="code">badarg</span>. Bad or invalid argument, possibly
bad type.
</p>
</li>
<li>
<p><span class="code">no_transaction</span>. Operation not allowed
outside transactions.
</p>
</li>
<li>
<p><span class="code">combine_error</span>. Table options were illegally
combined.
</p>
</li>
<li>
<p><span class="code">bad_index</span>. Index already exists or was out
of bounds.
</p>
</li>
<li>
<p><span class="code">already_exists</span>. Schema option is already set.
</p>
</li>
<li>
<p><span class="code">index_exists</span>. Some operations cannot be performed on
tabs with index.
</p>
</li>
<li>
<p><span class="code">no_exists</span>. Tried to perform operation on
non-existing, or not alive, item.
</p>
</li>
<li>
<p><span class="code">system_limit</span>. Some system_limit was exhausted.
</p>
</li>
<li>
<p><span class="code">mnesia_down</span>. A transaction involving
records at some remote node which died while
transaction was executing. Record(s) are no longer
available elsewhere in the network.
</p>
</li>
<li>
<p><span class="code">not_a_db_node</span>. A node which does not exist
in the schema was mentioned.
</p>
</li>
<li>
<p><span class="code">bad_type</span>. Bad type on some arguments.
</p>
</li>
<li>
<p><span class="code">node_not_running</span>. Node not running.
</p>
</li>
<li>
<p><span class="code">truncated_binary_file</span>. Truncated binary in file.
</p>
</li>
<li>
<p><span class="code">active</span>. Some delete operations require that
all active records are removed.
</p>
</li>
<li>
<p><span class="code">illegal</span>. Operation not supported on record.
</p>
</li>
</ul>
<p>The <span class="code">Error</span> may be <span class="code">Reason</span>,
<span class="code">{error, Reason}</span>, or <span class="code">{aborted, Reason}</span>. The
<span class="code">Reason</span> may be an atom or a tuple with <span class="code">Reason</span>
as an atom in the first field.</p>
</p></div>
<p><a name="ets-2"><span class="bold_code">ets(Fun, [, Args]) -> ResultOfFun | exit(Reason)</span></a><br></p>
<div class="REFBODY"><p>
<p>Call the <span class="code">Fun</span> in a raw context which is not protected by
a transaction. The Mnesia function call is performed in the
<span class="code">Fun</span> are performed directly on the local <span class="code">ets</span> tables on
the assumption that the local storage type is
<span class="code">ram_copies</span> and the tables are not replicated to other
nodes. Subscriptions are not triggered and checkpoints are
not updated, but it is extremely fast. This function can
also be applied to <span class="code">disc_copies</span> tables if all
operations are read only. See <span class="code">mnesia:activity/4</span>
and the Mnesia User's Guide for more details.</p>
<p><strong>Note:</strong> Calling (nesting) a <span class="code">mnesia:ets</span>
inside a transaction context will inherit the transaction semantics.</p>
</p></div>
<p><a name="first-1"><span class="bold_code">first(Tab) -> Key | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>Records in <span class="code">set</span> or <span class="code">bag</span> tables are not ordered.
However, there
is an ordering of the records which is not known
to the user. Accordingly, it is possible to traverse a table by means
of this function in conjunction with the <span class="code">mnesia:next/2</span>
function.
</p>
<p>If there are no records at all in the table, this function
returns the atom <span class="code">'$end_of_table'</span>. For this reason, it
is highly undesirable, but not disallowed, to use this atom
as the key for any user records.</p>
</p></div>
<p><a name="foldl-3"><span class="bold_code">foldl(Function, Acc, Table) -> NewAcc | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>Iterates over the table <span class="code">Table</span> and calls
<span class="code">Function(Record, NewAcc)</span> for each <span class="code">Record</span> in the table.
The term returned from <span class="code">Function</span> will be used as the second
argument in the next call to the <span class="code">Function</span>.
</p>
<p><span class="code">foldl</span> returns the same term as the last call to
<span class="code">Function</span> returned.</p>
</p></div>
<p><a name="foldr-3"><span class="bold_code">foldr(Function, Acc, Table) -> NewAcc | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>This function works exactly like
<span class="code">foldl/3</span> but iterates the table in the opposite order
for the <span class="code">ordered_set</span> table type. For
all other table types, <span class="code">foldr/3</span> and
<span class="code">foldl/3</span> are synonyms.</p>
</p></div>
<p><a name="force_load_table-1"><span class="bold_code">force_load_table(Tab) -> yes | ErrorDescription </span></a><br></p>
<div class="REFBODY"><p>
<p>The Mnesia algorithm for table load might lead to a
situation where a table cannot be loaded. This situation
occurs when a node is started and Mnesia concludes, or
suspects, that another copy of the table was active after
this local copy became inactive due to a system crash.
</p>
<p>If this situation is not acceptable, this function can be
used to override the strategy of the Mnesia table load
algorithm. This could lead to a situation where some
transaction effects are lost with a inconsistent database as
result, but for some applications high availability is more
important than consistent data.</p>
</p></div>
<p><a name="index_match_object-2"><span class="bold_code">index_match_object(Pattern, Pos) -> transaction abort | ObjList</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:index_match_object(Tab, Pattern, Pos, read)</span> where <span class="code">Tab</span> is <span class="code">element(1, Pattern)</span>.</p>
</p></div>
<p><a name="index_match_object-4"><span class="bold_code">index_match_object(Tab, Pattern, Pos, LockKind) -> transaction abort | ObjList</span></a><br></p>
<div class="REFBODY"><p>
<p>In a manner similar to the <span class="code">mnesia:index_read/3</span>
function, we can also utilize any index information when we
try to match records. This function takes a pattern which
obeys the same rules as the <span class="code">mnesia:match_object/3</span>
function with the exception that this function requires the
following conditions:
</p>
<ul>
<li>
<p>The table <span class="code">Tab</span> must have an index on
position <span class="code">Pos</span>.
</p>
</li>
<li>
<p>The element in position <span class="code">Pos</span> in
<span class="code">Pattern</span> must be bound. <span class="code">Pos</span> may either be
an integer (#record.Field), or an attribute name.</p>
</li>
</ul>
<p>The two index search functions described here are
automatically invoked when searching tables with <span class="code">qlc</span>
list comprehensions and also when using the low level
<span class="code">mnesia:[dirty_]match_object</span> functions.
</p>
<p></p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires a lock of type <span class="code">LockKind</span> on the
entire table or on a single record. Currently, the lock type
<span class="code">read</span> is supported.
</p>
</p></div>
<p><a name="index_read-3"><span class="bold_code">index_read(Tab, SecondaryKey, Pos) -> transaction abort | RecordList </span></a><br></p>
<div class="REFBODY"><p>
<p>Assume there is an index on position <span class="code">Pos</span> for a
certain record type. This function can be used to read the
records without knowing the actual key for the record. For
example, with an index in position 1 of the <span class="code">person</span>
table, the call <span class="code">mnesia:index_read(person, 36, #person.age)</span> returns a list of all persons with age
equal to 36. <span class="code">Pos</span> may also be an attribute name
(atom), but if the notation <span class="code">mnesia:index_read(person, 36, age)</span> is used, the field position will be searched for in
runtime, for each call.
</p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires a read lock on the entire table.</p>
</p></div>
<p><a name="info-0"><span class="bold_code">info() -> ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Prints some information about the system on the tty.
This function may be used even if Mnesia is not started.
However, more information will be displayed if Mnesia is
started.</p>
</p></div>
<p><a name="install_fallback-1"><span class="bold_code">install_fallback(Opaque) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:install_fallback(Opaque, Args)</span> where
<span class="code">Args</span> is <span class="code">[{scope, global}]</span>.</p>
</p></div>
<p><a name="install_fallback-1"><span class="bold_code">install_fallback(Opaque), BackupMod) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:install_fallback(Opaque, Args)</span> where
<span class="code">Args</span> is <span class="code">[{scope, global}, {module, BackupMod}]</span>.</p>
</p></div>
<p><a name="install_fallback-2"><span class="bold_code">install_fallback(Opaque, Args) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>This function is used to install a backup as fallback. The
fallback will be used to restore the database at the next
start-up. Installation of fallbacks requires Erlang to be up
and running on all the involved nodes, but it does not
matter if Mnesia is running or not. The installation of the
fallback will fail if the local node is not one of the disc
resident nodes in the backup.
</p>
<p><span class="code">Args</span> is a list of the following tuples:
</p>
<ul>
<li>
<p><span class="code">{module, BackupMod}</span>.
All accesses of the backup media is performed via a
callback module named <span class="code">BackupMod</span>. The
<span class="code">Opaque</span> argument is forwarded to the callback
module which may interpret it as it wish. The default
callback module is called <span class="code">mnesia_backup</span> and it
interprets the <span class="code">Opaque</span> argument as a local
filename. The default for this module is also
configurable via the <span class="code">-mnesia mnesia_backup</span>
configuration parameter. </p>
</li>
<li>
<p><span class="code">{scope, Scope}</span>
The <span class="code">Scope</span> of a fallback may either be
<span class="code">global</span> for the entire database or <span class="code">local</span>
for one node. By default, the installation of a fallback
is a global operation which either is performed all
nodes with disc resident schema or none. Which nodes
that are disc resident or not, is determined from the
schema info in the backup.</p>
<p>If the <span class="code">Scope</span> of the operation is <span class="code">local</span>
the fallback will only be installed on the local node.</p>
</li>
<li>
<p><span class="code">{mnesia_dir, AlternateDir}</span>
This argument is only valid if the scope of the
installation is <span class="code">local</span>. Normally the installation
of a fallback is targeted towards the Mnesia directory
as configured with the <span class="code">-mnesia dir</span> configuration
parameter. But by explicitly supplying an
<span class="code">AlternateDir</span> the fallback will be installed there
regardless of the Mnesia directory configuration
parameter setting. After installation of a fallback on
an alternate Mnesia directory that directory is fully
prepared for usage as an active Mnesia directory.
</p>
<p>This is a somewhat dangerous feature which must be
used with care. By unintentional mixing of directories
you may easily end up with a inconsistent database, if
the same backup is installed on more than one directory.</p>
</li>
</ul>
</p></div>
<p><a name="is_transaction-0"><span class="bold_code">is_transaction() -> boolean </span></a><br></p>
<div class="REFBODY"><p>
<p>When this function is executed inside a transaction context
it returns <span class="code">true</span>, otherwise <span class="code">false</span>.</p>
</p></div>
<p><a name="last-1"><span class="bold_code">last(Tab) -> Key | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>This function works exactly like
<span class="code">mnesia:first/1</span> but returns the last object in
Erlang term order for the <span class="code">ordered_set</span> table type. For
all other table types, <span class="code">mnesia:first/1</span> and
<span class="code">mnesia:last/1</span> are synonyms.</p>
</p></div>
<p><a name="load_textfile-1"><span class="bold_code">load_textfile(Filename)</span></a><br></p>
<div class="REFBODY"><p>
<p>Loads a series of definitions and data found in the
text file (generated with <span class="code">mnesia:dump_to_textfile/1</span>)
into Mnesia. This function also starts Mnesia and possibly
creates a new schema. This function is intended for
educational purposes only and using other functions to deal
with real backups, is recommended.</p>
</p></div>
<p><a name="lock-2"><span class="bold_code">lock(LockItem, LockKind) -> Nodes | ok | transaction abort</span></a><br></p>
<div class="REFBODY"><p>
<p>Write locks are normally acquired on all nodes where a
replica of the table resides (and is active). Read locks are
acquired on one node (the local node if a local
replica exists). Most of the context sensitive access functions
acquire an implicit lock if they are invoked in a
transaction context. The granularity of a lock may either
be a single record or an entire table.
</p>
<p>The normal usage is to call the function without checking
the return value since it exits if it fails and the
transaction is restarted by the transaction manager. It
returns all the locked nodes if a write lock is acquired, and
<span class="code">ok</span> if it was a read lock.
</p>
<p>This function <span class="code">mnesia:lock/2</span> is intended to support
explicit locking on tables but also intended for situations
when locks need to be acquired regardless of how tables are
replicated. Currently, two <span class="code">LockKind</span>'s are supported:
</p>
<dl>
<dt><strong><span class="code">write</span></strong></dt>
<dd>
<p>Write locks are exclusive, which means that if one
transaction manages to acquire a write lock on an item,
no other transaction may acquire any kind of lock on the
same item.
</p>
</dd>
<dt><strong><span class="code">read</span></strong></dt>
<dd>
<p>Read locks may be shared, which means that if one
transaction manages to acquire a read lock on an item,
other transactions may also acquire a read lock on the
same item. However, if someone has a read lock no one can
acquire a write lock at the same item. If some one has a
write lock no one can acquire a read lock nor
a write lock at the same item.</p>
</dd>
</dl>
<p>Conflicting lock requests are automatically queued if there
is no risk of a deadlock. Otherwise the transaction must be
aborted and executed again. Mnesia does this automatically
as long as the upper limit of maximum <span class="code">retries</span> is not
reached. See <span class="code">mnesia:transaction/3</span> for the details.
</p>
<p>For the sake of completeness sticky write locks will also
be described here even if a sticky write lock is not
supported by this particular function:
</p>
<dl>
<dt><strong><span class="code">sticky_write</span></strong></dt>
<dd>
<p>Sticky write locks are a mechanism which can be used
to optimize write lock acquisition. If your application
uses replicated tables mainly for fault tolerance (as
opposed to read access optimization purpose), sticky
locks may be the best option available.
</p>
<p>When a sticky write lock is acquired, all nodes will be
informed which node is locked. Subsequently,
sticky lock requests from the same node will be
performed as a local operation without any
communication with other nodes. The sticky lock
lingers on the node even after the transaction has
ended. See the Mnesia User's Guide for more information.</p>
</dd>
</dl>
<p>Currently, two kinds of <span class="code">LockItem</span>'s are supported by
this function:
</p>
<dl>
<dt><strong><span class="code">{table, Tab}</span></strong></dt>
<dd>
<p>This acquires a lock of type <span class="code">LockKind</span> on the
entire table <span class="code">Tab</span>.
</p>
</dd>
<dt><strong><span class="code">{global, GlobalKey, Nodes}</span></strong></dt>
<dd>
<p>This acquires a lock of type <span class="code">LockKind</span> on the
global resource <span class="code">GlobalKey</span>. The lock is acquired
on all active nodes in the <span class="code">Nodes</span> list. </p>
</dd>
</dl>
<p>Locks are released when the outermost transaction ends.
</p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires locks otherwise it just ignores the
request.</p>
</p></div>
<p><a name="match_object-1"><span class="bold_code">match_object(Pattern) ->transaction abort | RecList </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:match_object(Tab, Pattern, read)</span> where
<span class="code">Tab</span> is <span class="code">element(1, Pattern)</span>.</p>
</p></div>
<p><a name="match_object-3"><span class="bold_code">match_object(Tab, Pattern, LockKind) ->transaction abort | RecList </span></a><br></p>
<div class="REFBODY"><p>
<p>This function takes a pattern with 'don't care' variables
denoted as a '_' parameter. This function returns a list of
records which matched the pattern. Since the second element
of a record in a table is considered to be the key for the
record, the performance of this function depends on whether
this key is bound or not.
</p>
<p>For example, the call <span class="code">mnesia:match_object(person, {person, '_', 36, '_', '_'}, read)</span> returns a list of all person records with an
age field of thirty-six (36).
</p>
<p>The function <span class="code">mnesia:match_object/3</span>
automatically uses indices if these exist. However, no
heuristics are performed in order to select the best
index.
</p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires a lock of type <span class="code">LockKind</span> on the
entire table or a single record. Currently, the lock type
<span class="code">read</span> is supported.</p>
</p></div>
<p><a name="move_table_copy-3"><span class="bold_code">move_table_copy(Tab, From, To) -> {aborted, Reason} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>Moves the copy of table <span class="code">Tab</span> from node
<span class="code">From</span> to node <span class="code">To</span>.
</p>
<p>The storage type is preserved. For example, a RAM table
moved from one node remains a RAM on the new node. It is
still possible for other transactions to read and write in
the table while it is being moved.
</p>
<p>This function cannot be used on <span class="code">local_content</span> tables.</p>
</p></div>
<p><a name="next-2"><span class="bold_code">next(Tab, Key) -> Key | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>This function makes it possible to traverse a table
and perform operations on all records in the table. When
the end of the table is reached, the special key
<span class="code">'$end_of_table'</span> is returned. Otherwise, the function
returns a key which can be used to read the actual record.</p>
</p></div>
<p><a name="prev-2"><span class="bold_code">prev(Tab, Key) -> Key | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>This function works exactly like
<span class="code">mnesia:next/2</span> but returns the previous object in
Erlang term order for the ordered_set table type. For
all other table types, <span class="code">mnesia:next/2</span> and
<span class="code">mnesia:prev/2</span> are synonyms.</p>
</p></div>
<p><a name="read-1"><span class="bold_code">read({Tab, Key}) -> transaction abort | RecordList </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:read(Tab, Key, read)</span>.</p>
</p></div>
<p><a name="read-2"><span class="bold_code">read(Tab, Key) -> transaction abort | RecordList </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:read(Tab, Key, read)</span>.</p>
</p></div>
<p><a name="read-3"><span class="bold_code">read(Tab, Key, LockKind) -> transaction abort | RecordList </span></a><br></p>
<div class="REFBODY"><p>
<p>This function reads all records from table <span class="code">Tab</span> with
key <span class="code">Key</span>. This function has the same semantics
regardless of the location of <span class="code">Tab</span>. If the table is
of type <span class="code">bag</span>, the <span class="code">mnesia:read(Tab, Key)</span> can
return an arbitrarily long list. If the table is of type
<span class="code">set</span>, the list is either of length 1, or <span class="code">[]</span>.
</p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires a lock of type
<span class="code">LockKind</span>. Currently, the lock types <span class="code">read</span>,
<span class="code">write</span> and <span class="code">sticky_write</span> are supported.
</p>
<p>If the user wants to update the record it is more efficient to
use <span class="code">write/sticky_write</span> as the LockKind. If majority checking
is active on the table, it will be checked as soon as a write lock is
attempted. This can be used to quickly abort if the majority condition
isn't met.
</p>
</p></div>
<p><a name="read_lock_table-1"><span class="bold_code">read_lock_table(Tab) -> ok | transaction abort</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:lock({table, Tab}, read)</span>.</p>
</p></div>
<p><a name="report_event-1"><span class="bold_code">report_event(Event) -> ok</span></a><br></p>
<div class="REFBODY"><p>
<p>When tracing a system of Mnesia applications it is useful
to be able to interleave Mnesia's own events with
application related events that give information about the
application context.
</p>
<p>Whenever the application begins a
new and demanding Mnesia task, or if it is entering a new
interesting phase in its execution, it may be a good idea to
use <span class="code">mnesia:report_event/1</span>. The <span class="code">Event</span> may be
any term and generates a <span class="code">{mnesia_user, Event}</span> event
for any processes that subscribe to Mnesia system
events.</p>
</p></div>
<p><a name="restore-2"><span class="bold_code">restore(Opaque, Args) -> {atomic, RestoredTabs} |{aborted, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>With this function, tables may be restored online from a
backup without restarting Mnesia. <span class="code">Opaque</span> is forwarded
to the backup module. <span class="code">Args</span> is a list of the following
tuples:
</p>
<ul>
<li>
<p><span class="code">{module,BackupMod}</span> The backup module
<span class="code">BackupMod</span> will be used to access the backup
media. If omitted, the default backup module will be
used.
</p>
</li>
<li>
<span class="code">{skip_tables, TabList}</span> Where <span class="code">TabList</span>
is a list of tables which should not be read from the
backup.
</li>
<li>
<span class="code">{clear_tables, TabList}</span> Where
<span class="code">TabList</span> is a list of tables which should be
cleared, before the records from the backup are inserted,
ie. all records in the tables are deleted before the
tables are restored. Schema information about the tables
is not cleared or read from backup.
</li>
<li>
<span class="code">{keep_tables, TabList}</span> Where <span class="code">TabList</span>
is a list of tables which should be not be cleared, before
the records from the backup are inserted, i.e. the records
in the backup will be added to the records in the table.
Schema information about the tables is not cleared or read
from backup.
</li>
<li>
<span class="code">{recreate_tables, TabList}</span> Where
<span class="code">TabList</span> is a list of tables which should be
re-created, before the records from the backup are
inserted. The tables are first deleted and then created with
the schema information from the backup. All the nodes in the
backup needs to be up and running.
</li>
<li>
<span class="code">{default_op, Operation}</span> Where <span class="code">Operation</span> is
one of the following operations <span class="code">skip_tables</span>,
<span class="code">clear_tables</span>, <span class="code">keep_tables</span> or
<span class="code">recreate_tables</span>. The default operation specifies
which operation should be used on tables from the backup
which are not specified in any of the lists above. If
omitted, the operation <span class="code">clear_tables</span> will be used.
</li>
</ul>
<p>The affected tables are write locked during the
restoration, but regardless of the lock conflicts caused by
this, the applications can continue to do their work while
the restoration is being performed. The restoration is
performed as one single transaction.
</p>
<p>If the database is
huge, it may not be possible to restore it online. In such
cases, the old database must be restored by installing a
fallback and then restart.</p>
</p></div>
<p><a name="s_delete-1"><span class="bold_code">s_delete({Tab, Key}) -> ok | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:delete(Tab, Key, sticky_write)</span></p>
</p></div>
<p><a name="s_delete_object-1"><span class="bold_code">s_delete_object(Record) -> ok | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:delete_object(Tab, Record, sticky_write)</span> where <span class="code">Tab</span> is <span class="code">element(1, Record)</span>.</p>
</p></div>
<p><a name="s_write-1"><span class="bold_code">s_write(Record) -> ok | transaction abort </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:write(Tab, Record, sticky_write)</span>
where <span class="code">Tab</span> is <span class="code">element(1, Record)</span>.</p>
</p></div>
<p><a name="schema-0"><span class="bold_code">schema() -> ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Prints information about all table definitions on the tty.</p>
</p></div>
<p><a name="schema-1"><span class="bold_code">schema(Tab) -> ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Prints information about one table definition on the tty.</p>
</p></div>
<p><a name="select-2"><span class="bold_code">select(Tab, MatchSpec [, Lock]) -> transaction abort | [Object] </span></a><br></p>
<div class="REFBODY"><p>
<p>Matches the objects in the table <span class="code">Tab</span> using a
match_spec as described in the ERTS Users Guide. Optionally a lock
<span class="code">read</span> or <span class="code">write</span> can be given as the third
argument, default is <span class="code">read</span>. The return value depends
on the <span class="code">MatchSpec</span>.</p>
<p><strong>Note:</strong> for best performance <span class="code">select</span> should
be used before any modifying operations are done on that table
in the same transaction, i.e. don't use <span class="code">write</span> or <span class="code">delete</span>
before a <span class="code">select</span>.</p>
<p>In its simplest forms the match_spec's look like this:</p>
<ul>
<li>MatchSpec = [MatchFunction]</li>
<li>MatchFunction = {MatchHead, [Guard], [Result]}</li>
<li>MatchHead = tuple() | record()</li>
<li>Guard = {"Guardtest name", ...}</li>
<li>Result = "Term construct"</li>
</ul>
<p>See the ERTS Users Guide and <span class="code">ets</span> documentation for a
complete description of the select.</p>
<p>For example to find the names of all male persons with an age over 30 in table
Tab do:</p>
<div class="example"><pre>
MatchHead = #person{name='$1', sex=male, age='$2', _='_'},
Guard = {'>', '$2', 30},
Result = '$1',
mnesia:select(Tab,[{MatchHead, [Guard], [Result]}]),
</pre></div>
</p></div>
<p><a name="select-4"><span class="bold_code">select(Tab, MatchSpec, NObjects, Lock) -> transaction abort | {[Object],Cont} | '$end_of_table'</span></a><br></p>
<div class="REFBODY"><p>
<p>Matches the objects in the table <span class="code">Tab</span> using a
match_spec as described in ERTS users guide, and returns
a chunk of terms and a continuation, the wanted number
of returned terms is specified by the <span class="code">NObjects</span> argument.
The lock argument can be <span class="code">read</span> or <span class="code">write</span>.
The continuation should be used as argument to <span class="code">mnesia:select/1</span>,
if more or all answers are needed.</p>
<p><strong>Note:</strong> for best performance <span class="code">select</span> should
be used before any modifying operations are done on that
table in the same transaction, i.e. don't use
<span class="code">mnesia:write</span> or <span class="code">mnesia:delete</span> before a
<span class="code">mnesia:select</span>. For efficiency the <span class="code">NObjects</span> is
a recommendation only and the result may contain anything
from an empty list to all available results. </p>
</p></div>
<p><a name="select-1"><span class="bold_code">select(Cont) -> transaction abort | {[Object],Cont} | '$end_of_table'</span></a><br></p>
<div class="REFBODY"><p>
<p>Selects more objects with the match specification initiated
by <span class="code">mnesia:select/4</span>.
</p>
<p><strong>Note:</strong> Any modifying operations, i.e. <span class="code">mnesia:write</span>
or <span class="code">mnesia:delete</span>, that are done between the <span class="code">mnesia:select/4</span>
and <span class="code">mnesia:select/1</span> calls will not be visible in the result.</p>
</p></div>
<p><a name="set_debug_level-1"><span class="bold_code">set_debug_level(Level) -> OldLevel</span></a><br></p>
<div class="REFBODY"><p>
<p>Changes the internal debug level of Mnesia. See the
chapter about configuration parameters for details.</p>
</p></div>
<p><a name="set_master_nodes-1"><span class="bold_code">set_master_nodes(MasterNodes) -> ok | {error, Reason} </span></a><br></p>
<div class="REFBODY"><p>
<p>For each table Mnesia will determine its replica nodes
(<span class="code">TabNodes</span>) and invoke <span class="code">mnesia:set_master_nodes(Tab, TabMasterNodes)</span> where <span class="code">TabMasterNodes</span> is the
intersection of <span class="code">MasterNodes</span> and <span class="code">TabNodes</span>. See
<span class="code">mnesia:set_master_nodes/2</span> about the semantics.</p>
</p></div>
<p><a name="set_master_nodes-2"><span class="bold_code">set_master_nodes(Tab, MasterNodes) -> ok | {error, Reason} </span></a><br></p>
<div class="REFBODY"><p>
<p>If the application detects that there has been a
communication failure (in a potentially partitioned network) which
may have caused an inconsistent database, it may use the
function <span class="code">mnesia:set_master_nodes(Tab, MasterNodes)</span> to
define from which nodes each table will be loaded.
At startup Mnesia's normal table load algorithm will be
bypassed and the table will be loaded from one of the master
nodes defined for the table, regardless of when and if Mnesia
was terminated on other nodes. The <span class="code">MasterNodes</span> may only
contain nodes where the table has a replica and if the
<span class="code">MasterNodes</span> list is empty, the master node recovery
mechanism for the particular table will be reset and the
normal load mechanism will be used at next restart.
</p>
<p>The master node setting is always local and it may be
changed regardless of whether Mnesia is started or not.
</p>
<p>The database may also become inconsistent if the
<span class="code">max_wait_for_decision</span> configuration parameter is used
or if <span class="code">mnesia:force_load_table/1</span> is used.</p>
</p></div>
<p><a name="snmp_close_table-1"><span class="bold_code">snmp_close_table(Tab) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY"><p>
<p>Removes the possibility for SNMP to manipulate the
table.</p>
</p></div>
<p><a name="snmp_get_mnesia_key-2"><span class="bold_code">snmp_get_mnesia_key(Tab, RowIndex) -> {ok, Key} | undefined</span></a><br></p>
<div class="REFBODY">
<p>Types:</p>
<div class="REFTYPES">
<span class="bold_code">Tab ::= atom()</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">RowIndex ::= [integer()]</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">Key ::= key() | {key(), key(), ...}</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">key() ::= integer() | string() | [integer()]</span><br>
</div>
</div>
<div class="REFBODY"><p>
<p>Transforms an SNMP index to the corresponding Mnesia key.
If the SNMP table has multiple keys, the key is a tuple of
the key columns.</p>
</p></div>
<p><a name="snmp_get_next_index-2"><span class="bold_code">snmp_get_next_index(Tab, RowIndex) -> {ok, NextIndex} | endOfTable</span></a><br></p>
<div class="REFBODY">
<p>Types:</p>
<div class="REFTYPES">
<span class="bold_code">Tab ::= atom()</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">RowIndex ::= [integer()]</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">NextIndex ::= [integer()]</span><br>
</div>
</div>
<div class="REFBODY"><p>
<p>The <span class="code">RowIndex</span> may specify a non-existing row.
Specifically, it might be the empty list. Returns the index
of the next lexicographical row. If <span class="code">RowIndex</span> is the
empty list, this function will return the index of the first row
in the table.</p>
</p></div>
<p><a name="snmp_get_row-2"><span class="bold_code">snmp_get_row(Tab, RowIndex) -> {ok, Row} | undefined</span></a><br></p>
<div class="REFBODY">
<p>Types:</p>
<div class="REFTYPES">
<span class="bold_code">Tab ::= atom()</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">RowIndex ::= [integer()]</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">Row ::= record(Tab)</span><br>
</div>
</div>
<div class="REFBODY"><p>
<p>Makes it possible to read a row by its SNMP index. This
index is specified as an SNMP OBJECT IDENTIFIER, a list of
integers.</p>
</p></div>
<p><a name="snmp_open_table-2"><span class="bold_code">snmp_open_table(Tab, SnmpStruct) -> {aborted, R} | {atomic, ok}</span></a><br></p>
<div class="REFBODY">
<p>Types:</p>
<div class="REFTYPES">
<span class="bold_code">Tab ::= atom()</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">SnmpStruct ::= [{key, type()}]</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">type() ::= type_spec() | {type_spec(), type_spec(), ...}</span><br>
</div>
<div class="REFTYPES">
<span class="bold_code">type_spec() ::= fix_string | string | integer</span><br>
</div>
</div>
<div class="REFBODY"><p>
<p>It is possible to establish a direct one to one mapping
between Mnesia tables and SNMP tables. Many
telecommunication applications are controlled and monitored
by the SNMP protocol. This connection between Mnesia and
SNMP makes it simple and convenient to achieve this.
</p>
<p>The <span class="code">SnmpStruct</span> argument is a list of SNMP
information. Currently, the only information needed is
information about the key types in the table. It is not
possible to handle multiple keys in Mnesia, but many SNMP
tables have multiple keys. Therefore, the following
convention is used: if a table has multiple keys, these must
always be stored as a tuple of the keys. Information about
the key types is specified as a tuple of atoms describing
the types. The only significant type is
<span class="code">fix_string</span>. This means that a string has fixed
size. For example:
</p>
<div class="example"><pre>
mnesia:snmp_open_table(person, [{key, string}])
</pre></div>
<p>causes the <span class="code">person</span> table to be ordered as an SNMP
table.
</p>
<p>Consider the following schema for a table of company
employees. Each employee is identified by department number
and name. The other table column stores the telephone number:
</p>
<div class="example"><pre>
mnesia:create_table(employee,
[{snmp, [{key, {integer, string}}]},
{attributes, record_info(fields, employees)}]),
</pre></div>
<p>The corresponding SNMP table would have three columns;
<span class="code">department</span>, <span class="code">name</span> and <span class="code">telno</span>.
</p>
<p>It is possible to have table columns that are not visible
through the SNMP protocol. These columns must be the last
columns of the table. In the previous example, the SNMP
table could have columns <span class="code">department</span> and <span class="code">name</span>
only. The application could then use the <span class="code">telno</span> column
internally, but it would not be visible to the SNMP
managers.
</p>
<p>In a table monitored by SNMP, all elements must be
integers, strings, or lists of integers.
</p>
<p>When a table is SNMP ordered, modifications are more
expensive than usual, O(logN). And more memory is used.
</p>
<p><strong>Note:</strong>Only the lexicographical SNMP ordering is
implemented in Mnesia, not the actual SNMP monitoring.</p>
</p></div>
<p><a name="start-0"><span class="bold_code">start() -> ok | {error, Reason} </span></a><br></p>
<div class="REFBODY"><p>
<p>The start-up procedure for a set of Mnesia nodes is a
fairly complicated operation. A Mnesia system consists of a set
of nodes, with Mnesia started locally on all
participating nodes. Normally, each node has a directory where
all the Mnesia files are written. This directory will be
referred to as the Mnesia directory. Mnesia may also be
started on disc-less nodes. See <span class="code">mnesia:create_schema/1</span>
and the Mnesia User's Guide for more information about disc-less
nodes.
</p>
<p>The set of nodes which makes up a Mnesia system is kept in
a schema and it is possible to add and remove Mnesia nodes
from the schema. The initial schema is normally created on
disc with the function <span class="code">mnesia:create_schema/1</span>. On
disc-less nodes, a tiny default schema is generated each time
Mnesia is started. During the start-up procedure, Mnesia
will exchange schema information between the nodes in order
to verify that the table definitions are compatible.
</p>
<p>Each schema has a unique cookie which may be regarded as a
unique schema identifier. The cookie must be the same on all
nodes where Mnesia is supposed to run. See the Mnesia
User's Guide for more information about these details.
</p>
<p>The schema file, as well as all other files which Mnesia
needs, are kept in the Mnesia directory. The command line
option <span class="code">-mnesia dir Dir</span> can be used to specify the
location of this directory to the Mnesia system. If no such
command line option is found, the name of the directory
defaults to <span class="code">Mnesia.Node</span>.
</p>
<p><span class="code">application:start(mnesia)</span> may also be used.</p>
</p></div>
<p><a name="stop-0"><span class="bold_code">stop() -> stopped </span></a><br></p>
<div class="REFBODY"><p>
<p>Stops Mnesia locally on the current node.
</p>
<p><span class="code">application:stop(mnesia)</span> may also be used.</p>
</p></div>
<p><a name="subscribe-1"><span class="bold_code">subscribe(EventCategory)</span></a><br></p>
<div class="REFBODY"><p>
<p>Ensures that a copy of all events of type
<span class="code">EventCategory</span> are sent to the caller. The event
types available are described in the Mnesia User's Guide.</p>
</p></div>
<p><a name="sync_dirty-2"><span class="bold_code">sync_dirty(Fun, [, Args]) -> ResultOfFun | exit(Reason) </span></a><br></p>
<div class="REFBODY"><p>
<p>Call the <span class="code">Fun</span> in a context which is not protected
by a transaction. The Mnesia function calls performed in the
<span class="code">Fun</span> are mapped to the corresponding dirty functions.
It is performed in almost the same context as
<span class="code">mnesia:async_dirty/1,2</span>. The difference is that the
operations are performed synchronously. The caller waits for
the updates to be performed on all active replicas before
the <span class="code">Fun</span> returns. See <span class="code">mnesia:activity/4</span> and the
Mnesia User's Guide for more details.</p>
</p></div>
<p><a name="sync_transaction-3"><span class="bold_code">sync_transaction(Fun, [[, Args], Retries]) -> {aborted, Reason} | {atomic, ResultOfFun} </span></a><br></p>
<div class="REFBODY"><p>
<p>This function waits until data have been committed and
logged to disk (if disk is used) on every involved node before
it returns, otherwise it behaves as
<span class="code">mnesia:transaction/[1,2,3]</span>.</p>
<p>This functionality can be used to avoid that one process may overload
a database on another node.</p>
</p></div>
<p><a name="system_info-1"><span class="bold_code">system_info(InfoKey) -> Info | exit({aborted, Reason})</span></a><br></p>
<div class="REFBODY"><p>
<p>Returns information about the Mnesia system, such as
transaction statistics, db_nodes, and configuration parameters.
Valid keys are:</p>
<ul>
<li>
<p><span class="code">all</span>. This argument returns a list of all
local system information. Each element is a
<span class="code">{InfoKey, InfoVal}</span> tuples.<strong>Note:</strong> New <span class="code">InfoKey</span>'s may
be added and old undocumented <span class="code">InfoKey</span>'s may be removed without
notice.</p>
</li>
<li>
<p><span class="code">access_module</span>. This argument returns the name of
the module which is configured to be the activity access
callback module.
</p>
</li>
<li>
<p><span class="code">auto_repair</span>. This argument returns
<span class="code">true</span> or <span class="code">false</span> to indicate if Mnesia is
configured to invoke the auto repair facility on corrupted
disc files.
</p>
</li>
<li>
<p><span class="code">backup_module</span>. This argument returns the name of
the module which is configured to be the backup
callback module.
</p>
</li>
<li>
<p><span class="code">checkpoints</span>. This argument
returns a list of the names of the
checkpoints currently active on this node.
</p>
</li>
<li>
<p><span class="code">event_module</span>. This argument returns the name of
the module which is the event handler callback module.
</p>
</li>
<li>
<p><span class="code">db_nodes</span>. This argument returns
the nodes which make up the persistent database. Disc
less nodes will only be included in the list of nodes if
they explicitly has been added to the schema, e.g. with
<span class="code">mnesia:add_table_copy/3</span>. The function can be
invoked even if Mnesia is not yet running.
</p>
</li>
<li>
<p><span class="code">debug</span>. This argument returns the current
debug level of Mnesia.
</p>
</li>
<li>
<p><span class="code">directory</span>. This argument returns the name of
the Mnesia directory. It can be invoked even if Mnesia is
not yet running.
</p>
</li>
<li>
<p><span class="code">dump_log_load_regulation</span>. This argument
returns a boolean which tells whether Mnesia is
configured to load regulate the dumper process or not.
This feature is temporary and will disappear in future
releases.
</p>
</li>
<li>
<p><span class="code">dump_log_time_threshold</span>. This argument
returns the time threshold for transaction log dumps in
milliseconds.
</p>
</li>
<li>
<p><span class="code">dump_log_update_in_place</span>. This argument
returns a boolean which tells whether Mnesia is
configured to perform the updates in the dets files
directly or if the updates should be performed in a copy
of the dets files.
</p>
</li>
<li>
<p><span class="code">dump_log_write_threshold</span>. This argument
returns the write threshold for transaction log dumps as
the number of writes to the transaction log.
</p>
</li>
<li>
<p><span class="code">extra_db_nodes</span>. This argument returns a list
of extra db_nodes to be contacted at start-up.
</p>
</li>
<li>
<p><span class="code">fallback_activated</span>. This argument returns
true if a fallback is activated, otherwise false.
</p>
</li>
<li>
<p><span class="code">held_locks</span>. This argument returns a list of
all locks held by the local Mnesia lock manager.
</p>
</li>
<li>
<p><span class="code">is_running</span>. This argument returns <span class="code">yes</span>
or <span class="code">no</span> to indicate if Mnesia is running. It may
also return <span class="code">starting</span> or <span class="code">stopping</span>. Can be
invoked even if Mnesia is not yet running.
</p>
</li>
<li>
<p><span class="code">local_tables</span>. This argument returns a list
of all tables which are configured to reside locally.
</p>
</li>
<li>
<p><span class="code">lock_queue</span>. This argument returns a list of
all transactions that are queued for execution by the
local lock manager.
</p>
</li>
<li>
<p><span class="code">log_version</span>. This argument returns the
version number of the Mnesia transaction log format.
</p>
</li>
<li>
<p><span class="code">master_node_tables</span>. This argument returns a
list of all tables with at least one master node.
</p>
</li>
<li>
<p><span class="code">protocol_version</span>. This argument
returns the version number
of the Mnesia inter-process communication protocol.
</p>
</li>
<li>
<p><span class="code">running_db_nodes</span>. This argument returns a
list of nodes where Mnesia currently is running. This
function can be invoked even if Mnesia is not yet
running, but it will then have slightly different
semantics. If Mnesia is down on the local node, the
function will return those other <span class="code">db_nodes</span> and
<span class="code">extra_db_nodes</span> that for the moment are up and
running. If Mnesia is started, the function will return
those nodes that Mnesia on the local node is fully
connected to. Only those nodes that Mnesia has exchanged
schema information with are included as
<span class="code">running_db_nodes</span>. After the merge of schemas, the
local Mnesia system is fully operable and applications
may perform access of remote replicas. Before the schema
merge Mnesia will only operate locally. Sometimes there
may be more nodes included in the
<span class="code">running_db_nodes</span> list than all <span class="code">db_nodes</span>
and <span class="code">extra_db_nodes</span> together.
</p>
</li>
<li>
<p><span class="code">schema_location</span>. This argument returns the
initial schema location.
</p>
</li>
<li>
<p><span class="code">subscribers</span>. This argument returns a list of
local processes currently subscribing to system events.
</p>
</li>
<li>
<p><span class="code">tables</span>. This argument returns a list of all
locally known tables.
</p>
</li>
<li>
<p><span class="code">transactions</span>. This argument returns a list
of all currently active local transactions.
</p>
</li>
<li>
<p><span class="code">transaction_failures</span>. This argument returns
a number which indicates how many transactions have
failed since Mnesia was started.
</p>
</li>
<li>
<p><span class="code">transaction_commits</span>. This argument returns a
number which indicates how many transactions have
terminated successfully since Mnesia was started.
</p>
</li>
<li>
<p><span class="code">transaction_restarts</span>. This argument returns
a number which indicates how many transactions have been
restarted since Mnesia was started.
</p>
</li>
<li>
<p><span class="code">transaction_log_writes</span>. This argument
returns a number which indicates the number of write
operation that have been performed to the transaction
log since start-up.
</p>
</li>
<li>
<p><span class="code">use_dir</span>. This argument returns a boolean
which indicates whether the Mnesia directory is used or
not. Can be invoked even if Mnesia is not yet running.
</p>
</li>
<li>
<p><span class="code">version</span>. This argument returns the current
version number of Mnesia.
</p>
</li>
</ul>
</p></div>
<p><a name="table-1"><span class="bold_code">table(Tab [,[Option]]) -> QueryHandle </span></a><br></p>
<div class="REFBODY"><p>
<p> <a name="qlc_table"></a>
Returns a QLC (Query List Comprehension) query handle, see
<span class="bold_code"><a href="javascript:erlhref('../../../../doc/../','stdlib','qlc.html');">qlc(3)</a></span>.The module <span class="code">qlc</span> implements a query language, it
can use mnesia tables as sources of data. Calling
<span class="code">mnesia:table/1,2</span> is the means to make the <span class="code">mnesia</span>
table <span class="code">Tab</span> usable to QLC.</p>
<p>The list of Options may contain mnesia options or QLC
options, the following options are recognized by Mnesia:
<span class="code">{traverse, SelectMethod},{lock, Lock},{n_objects,Number}</span>, any other option is forwarded
to QLC. The <span class="code">lock</span> option may be <span class="code">read</span> or
<span class="code">write</span>, default is <span class="code">read</span>. The option
<span class="code">n_objects</span> specifies (roughly) the number of objects
returned from mnesia to QLC. Queries to remote tables may
need a larger chunks to reduce network overhead, default
<span class="code">100</span> objects at a time are returned. The option
<span class="code">traverse</span> determines the method to traverse the whole
table (if needed), the default method is <span class="code">select</span>:</p>
<ul>
<li>
<p><span class="code">select</span>. The table is traversed by calling
<span class="code">mnesia:select/4</span> and <span class="code">mnesia:select/1</span>. The
match specification (the second argument of <span class="code">select/3</span>)
is assembled by QLC: simple filters are
translated into equivalent match specifications while
more complicated filters have to be applied to all
objects returned by <span class="code">select/3</span> given a match
specification that matches all objects.</p>
</li>
<li>
<p><span class="code">{select, MatchSpec}</span>. As for <span class="code">select</span>
the table is traversed by calling <span class="code">mnesia:select/3</span> and
<span class="code">mnesia:select/1</span>. The difference is that the match
specification is explicitly given. This is how to state
match specifications that cannot easily be expressed
within the syntax provided by QLC.</p>
</li>
</ul>
</p></div>
<p><a name="table_info-2"><span class="bold_code">table_info(Tab, InfoKey) -> Info | exit({aborted, Reason})</span></a><br></p>
<div class="REFBODY"><p>
<p>The <span class="code">table_info/2</span> function takes two arguments.
The first is the name of a Mnesia table, the second is one of
the following keys:
</p>
<ul>
<li>
<p><span class="code">all</span>. This argument returns a list of all
local table information. Each element is a <span class="code">{InfoKey, ItemVal}</span> tuples. <strong>Note:</strong> New <span class="code">InfoItem</span>'s may be
added and old undocumented <span class="code">InfoItem</span>'s may be removed without
notice.</p>
</li>
<li>
<p><span class="code">access_mode</span>. This argument returns the
access mode of the table. The access mode may either be
read_only or read_write.
</p>
</li>
<li>
<p><span class="code">arity</span>. This argument returns the arity of
records in the table as specified in the schema.
</p>
</li>
<li>
<p><span class="code">attributes</span>. This argument returns the table
attribute names which are specified in the schema.
</p>
</li>
<li>
<p><span class="code">checkpoints</span>. This argument returns the names
of the currently active checkpoints which involves this
table on this node.
</p>
</li>
<li>
<p><span class="code">cookie</span>. This argument returns a table cookie
which is a unique system generated identifier for the
table. The cookie is used internally to ensure that two
different table definitions using the same table name
cannot accidentally be intermixed. The cookie is
generated when the table is initially created.
</p>
</li>
<li>
<p><span class="code">disc_copies</span>. This argument returns the nodes
where a disc_copy of the table resides according to the
schema.
</p>
</li>
<li>
<p><span class="code">disc_only_copies </span>. This argument returns the
nodes where a disc_only_copy of the table resides
according to the schema.
</p>
</li>
<li>
<p><span class="code">index</span>. This argument returns the list of
index position integers for the table.
</p>
</li>
<li>
<p><span class="code">load_node</span>. This argument returns the name of
the node that Mnesia loaded the table from. The
structure of the returned value is unspecified but may
be useful for debugging purposes.
</p>
</li>
<li>
<p><span class="code">load_order</span>. This argument returns the load
order priority of the table. It is an integer and
defaults to <span class="code">0</span> (zero).
</p>
</li>
<li>
<p><span class="code">load_reason</span>. This argument returns the
reason of why Mnesia decided to load the table. The
structure of the returned value is unspecified but may
be useful for debugging purposes.
</p>
</li>
<li>
<p><span class="code">local_content</span>. This argument returns
<span class="code">true</span> or <span class="code">false</span> to indicate whether the
table is configured to have locally unique content on
each node.
</p>
</li>
<li>
<p><span class="code">master_nodes</span>. This argument returns the
master nodes of a table.
</p>
</li>
<li>
<p><span class="code">memory</span>. This argument returns the number of
words allocated to the table on this node.
</p>
</li>
<li>
<p><span class="code">ram_copies</span>. This argument returns the nodes
where a ram_copy of the table resides according to the
schema.
</p>
</li>
<li>
<p><span class="code">record_name</span>. This argument returns the
record name, common for all records in the table
</p>
</li>
<li>
<p><span class="code">size</span>. This argument returns the number of
records inserted in the table.
</p>
</li>
<li>
<p><span class="code">snmp</span>. This argument returns the SNMP struct.
<span class="code">[]</span>meaning that the table currently has no SNMP
properties.
</p>
</li>
<li>
<p><span class="code">storage_type</span>.This argument returns the local
storage type of the table. It can be <span class="code">disc_copies</span>,
<span class="code">ram_copies</span>, <span class="code">disc_only_copies</span>, or the atom
<span class="code">unknown</span>. <span class="code">unknown</span> is returned for all
tables which only reside remotely.
</p>
</li>
<li>
<p><span class="code">subscribers</span>. This argument returns a list
of local processes currently subscribing to local table
events which involve this table on this node.
</p>
</li>
<li>
<p><span class="code">type</span>. This argument returns the table type,
which is either <span class="code">bag</span>, <span class="code">set</span> or <span class="code">ordered_set</span>..
</p>
</li>
<li>
<p><span class="code">user_properties</span>. This argument returns the
user associated table properties of the table. It is a
list of the stored property records.
</p>
</li>
<li>
<p><span class="code">version</span>. This argument returns the current
version of the table definition. The table version is
incremented when the table definition is changed. The
table definition may be incremented directly when the
table definition has been changed in a schema
transaction, or when a committed table definition is
merged with table definitions from other nodes during
start-up.
</p>
</li>
<li>
<p><span class="code">where_to_read</span>.This argument returns the node
where the table can be read. If the value <span class="code">nowhere</span>
is returned, the table is not loaded, or it resides at a
remote node which is not running.
</p>
</li>
<li>
<p><span class="code">where_to_write</span>. This argument returns a list
of the nodes that currently hold an active replica of
the table.
</p>
</li>
<li>
<p><span class="code">wild_pattern</span>. This argument returns a
structure which can be given to the various match
functions for a certain table. A record tuple is where all
record fields have the value <span class="code">'_'</span>.
</p>
</li>
</ul>
</p></div>
<p><a name="transaction-2"><span class="bold_code">transaction(Fun [[, Args], Retries]) -> {aborted, Reason} | {atomic, ResultOfFun}</span></a><br></p>
<div class="REFBODY"><p>
<p>This function executes the functional object <span class="code">Fun</span>
with arguments <span class="code">Args</span> as a transaction.
</p>
<p>The code which executes inside the transaction
can consist of a series of table manipulation functions.
If something goes wrong inside the transaction as a result of a
user error or a certain table not being available, the
entire transaction is aborted and the function
<span class="code">transaction/1</span> returns the tuple
<span class="code">{aborted, Reason}</span>.
</p>
<p>If all is well, <span class="code">{atomic, ResultOfFun}</span> is returned where
<span class="code">ResultOfFun</span> is the value of the last expression in
<span class="code">Fun</span>.
</p>
<p>A function which adds a family to the database can be
written as follows if we have a structure <span class="code">{family, Father, Mother, ChildrenList}</span>:
</p>
<div class="example"><pre>
add_family({family, F, M, Children}) ->
ChildOids = lists:map(fun oid/1, Children),
Trans = fun() ->
mnesia:write(F#person{children = ChildOids},
mnesia:write(M#person{children = ChildOids},
Write = fun(Child) -> mnesia:write(Child) end,
lists:foreach(Write, Children)
end,
mnesia:transaction(Trans).
oid(Rec) -> {element(1, Rec), element(2, Rec)}.
</pre></div>
<p>This code adds a set of people to the database. Running this code
within one transaction will ensure that either the whole
family is added to the database, or the whole transaction
aborts. For example, if the last child is badly formatted,
or the executing process terminates due to an
<span class="code">'EXIT'</span> signal while executing the family code, the
transaction aborts. Accordingly, the situation where half a
family is added can never occur.
</p>
<p>It is also useful to update the database within a transaction
if several processes concurrently update the same records.
For example, the function <span class="code">raise(Name, Amount)</span>, which
adds <span class="code">Amount</span> to the salary field of a person, should
be implemented as follows:
</p>
<div class="example"><pre>
raise(Name, Amount) ->
mnesia:transaction(fun() ->
case mnesia:wread({person, Name}) of
[P] ->
Salary = Amount + P#person.salary,
P2 = P#person{salary = Salary},
mnesia:write(P2);
_ ->
mnesia:abort("No such person")
end
end).
</pre></div>
<p>When this function executes within a transaction,
several processes running on different nodes can concurrently
execute the <span class="code">raise/2</span> function without interfering
with each other.
</p>
<p>Since Mnesia detects deadlocks, a transaction can be
restarted any number of times. This function will attempt a restart as specified in
<span class="code">Retries</span>. <span class="code">Retries</span> must
be an integer greater than 0 or the atom <span class="code">infinity</span>. Default is
<span class="code">infinity</span>.</p>
</p></div>
<p><a name="transform_table-4"><span class="bold_code">transform_table(Tab, Fun, NewAttributeList, NewRecordName) -> {aborted, R} | {atomic, ok} </span></a><br></p>
<div class="REFBODY"><p>
<p>This function applies the argument <span class="code">Fun</span> to all
records in the table. <span class="code">Fun</span> is a function which takes a
record of the old type and returns a transformed record of the
new type. The <span class="code">Fun</span> argument can also be the atom
<span class="code">ignore</span>, it indicates that only the meta data about the table will
be updated. Usage of <span class="code">ignore</span> is not recommended but included
as a possibility for the user do to his own transform.
<span class="code">NewAttributeList</span> and <span class="code">NewRecordName</span>
specifies the attributes and the new record type of converted
table. Table name will always remain unchanged, if the
record_name is changed only the mnesia functions which
uses table identifiers will work, e.g. <span class="code">mnesia:write/3</span>
will work but <span class="code">mnesia:write/1</span> will not.</p>
</p></div>
<p><a name="transform_table-3"><span class="bold_code">transform_table(Tab, Fun, NewAttributeList) -> {aborted, R} | {atomic, ok} </span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:transform_table(Tab, Fun, NewAttributeList, RecName)</span>
where <span class="code">RecName</span> is <span class="code">mnesia:table_info(Tab, record_name)</span>.</p>
</p></div>
<p><a name="traverse_backup-4"><span class="bold_code">traverse_backup(Source, [SourceMod,] Target, [TargetMod,] Fun, Acc) -> {ok, LastAcc} | {error, Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>With this function it is possible to iterate over a backup,
either for the purpose of transforming it into a new backup,
or just reading it. The arguments are explained briefly
below. See the Mnesia User's Guide for additional
details.
</p>
<ul>
<li>
<span class="code">SourceMod</span> and <span class="code">TargetMod</span> are the names of
the modules which actually access the backup
media.
</li>
<li>
<span class="code">Source</span> and <span class="code">Target</span> are opaque data used
exclusively by the modules <span class="code">SourceMod</span> and
<span class="code">TargetMod</span> for the purpose of initializing the
backup media.
</li>
<li>
<span class="code">Acc</span> is an initial accumulator value.
</li>
<li>
<span class="code">Fun(BackupItems, Acc)</span> is applied to each item in
the backup. The Fun must return a tuple
<span class="code">{BackupItems,NewAcc}</span>, where <span class="code">BackupItems</span> is
a list of valid backup items, and <span class="code">NewAcc</span> is a new
accumulator value. The returned backup items are written
in the target backup.
</li>
<li>
<span class="code">LastAcc</span> is the last accumulator value. This is
the last <span class="code">NewAcc</span> value that was returned by <span class="code">Fun</span>.
</li>
</ul>
</p></div>
<p><a name="uninstall_fallback-0"><span class="bold_code">uninstall_fallback() -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:uninstall_fallback([{scope, global}])</span>.</p>
</p></div>
<p><a name="uninstall_fallback-1"><span class="bold_code">uninstall_fallback(Args) -> ok | {error,Reason}</span></a><br></p>
<div class="REFBODY"><p>
<p>This function is used to de-install a fallback before it
has been used to restore the database. This is normally a
distributed operation that is either performed on all
nodes with disc resident schema or none. Uninstallation of
fallbacks requires Erlang to be up and running on all
involved nodes, but it does not matter if Mnesia is running
or not. Which nodes that are considered as disc-resident
nodes is determined from the schema info in the local
fallback.
</p>
<p><span class="code">Args</span> is a list of the following tuples:
</p>
<ul>
<li>
<p><span class="code">{module, BackupMod}</span>.
See <span class="code">mnesia:install_fallback/2</span> about the
semantics.</p>
</li>
<li>
<p><span class="code">{scope, Scope}</span>
See <span class="code">mnesia:install_fallback/2</span> about the
semantics.</p>
</li>
<li>
<p><span class="code">{mnesia_dir, AlternateDir}</span>
See <span class="code">mnesia:install_fallback/2</span> about the
semantics.</p>
</li>
</ul>
</p></div>
<p><a name="unsubscribe-1"><span class="bold_code">unsubscribe(EventCategory)</span></a><br></p>
<div class="REFBODY"><p>
<p>Stops sending events of type
<span class="code">EventCategory</span> to the caller.</p>
</p></div>
<p><a name="wait_for_tables-2"><span class="bold_code">wait_for_tables(TabList,Timeout) -> ok | {timeout, BadTabList} | {error, Reason} </span></a><br></p>
<div class="REFBODY"><p>
<p>Some applications need to wait for certain tables to
be accessible in order to do useful work.
<span class="code">mnesia:wait_for_tables/2</span> hangs until all tables in the
<span class="code">TabList</span> are accessible, or until <span class="code">timeout</span> is
reached.</p>
</p></div>
<p><a name="wread-1"><span class="bold_code">wread({Tab, Key}) -> transaction abort | RecordList </span></a><br></p>
<div class="REFBODY"><p>
<p>Invoke <span class="code">mnesia:read(Tab, Key, write)</span>.</p>
</p></div>
<p><a name="write-1"><span class="bold_code">write(Record) -> transaction abort | ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Invoke <span class="code">mnesia:write(Tab, Record, write)</span> where
<span class="code">Tab</span> is <span class="code">element(1, Record)</span>.</p>
</p></div>
<p><a name="write-3"><span class="bold_code">write(Tab, Record, LockKind) -> transaction abort | ok </span></a><br></p>
<div class="REFBODY"><p>
<p>Writes the record <span class="code">Record</span> to the table <span class="code">Tab</span>.
</p>
<p>The function returns <span class="code">ok</span>, or aborts if an error
occurs. For example, the transaction aborts if no
<span class="code">person</span> table exists.
</p>
<p>The semantics of this function is context sensitive. See
<span class="code">mnesia:activity/4</span> for more information. In transaction
context it acquires a lock of type <span class="code">LockKind</span>. The
following lock types are supported: <span class="code">write</span> and
<span class="code">sticky_write</span>.</p>
</p></div>
<p><a name="write_lock_table-1"><span class="bold_code">write_lock_table(Tab) -> ok | transaction abort</span></a><br></p>
<div class="REFBODY"><p>
<p>Invokes <span class="code">mnesia:lock({table, Tab}, write)</span>.</p>
</p></div>
<h3><a name="id65456">Configuration Parameters</a></h3>
<div class="REFBODY">
<p>Mnesia reads the following application configuration
parameters:</p>
<ul>
<li>
<p><span class="code">-mnesia access_module Module</span>. The
name of the Mnesia activity access callback module. The default is
<span class="code">mnesia</span>.
</p>
</li>
<li>
<p><span class="code">-mnesia auto_repair true | false</span>. This flag controls
whether Mnesia will try to automatically repair
files that have not been properly closed. The default is
<span class="code">true</span>.
</p>
</li>
<li>
<p><span class="code">-mnesia backup_module Module</span>. The
name of the Mnesia backup callback module. The default is
<span class="code">mnesia_backup</span>.
</p>
</li>
<li>
<p><span class="code">-mnesia debug Level</span>
Controls the debug level of Mnesia.
Possible values are:</p>
<dl>
<dt><strong><span class="code">none</span></strong></dt>
<dd>
<p>No trace outputs at all. This is the default setting.
</p>
</dd>
<dt><strong><span class="code">verbose</span></strong></dt>
<dd>
<p>Activates tracing of important debug events. These
debug events generate <span class="code">{mnesia_info, Format, Args}</span>
system events. Processes may subscribe to these events with
<span class="code">mnesia:subscribe/1</span>. The events are always sent to Mnesia's
event handler.
</p>
</dd>
<dt><strong><span class="code">debug</span></strong></dt>
<dd>
<p>Activates all events at the verbose level plus full
trace of all debug events. These debug events generate
<span class="code">{mnesia_info, Format, Args}</span> system events. Processes may
subscribe to these events with <span class="code">mnesia:subscribe/1</span>. The
events are always sent to the Mnesia event handler. On this
debug level, the Mnesia event handler starts subscribing to
updates in the schema table.
</p>
</dd>
<dt><strong><span class="code">trace</span></strong></dt>
<dd>
<p>Activates all events at the level debug. On this
debug level, the Mnesia event handler starts subscribing to
updates on all Mnesia tables. This level is only intended
for debugging small toy systems since many large
events may be generated.
</p>
</dd>
<dt><strong><span class="code">false</span></strong></dt>
<dd>
<p>An alias for none.
</p>
</dd>
<dt><strong><span class="code">true</span></strong></dt>
<dd>
<p>An alias for debug.
</p>
</dd>
</dl>
</li>
<li>
<p><span class="code">-mnesia core_dir Directory</span>. The name of the
directory where Mnesia core files is stored or
false. Setting it implies that also ram only nodes, will
generate a core file if a crash occurs. </p>
</li>
<li>
<p><span class="code">-mnesia dc_dump_limit Number</span>.
Controls how often <span class="code">disc_copies</span> tables are dumped from memory.
Tables are dumped when
<span class="code">filesize(Log) > (filesize(Tab)/Dc_dump_limit)</span>.
Lower values reduces cpu overhead but increases disk space and
startup times. The default is 4.</p>
</li>
<li>
<p><span class="code">-mnesia dir Directory</span>. The name of the directory
where all Mnesia data is stored. The name of the directory must
be unique for the current node. Two nodes may, under no
circumstances, share the same Mnesia directory. The results are
totally unpredictable.</p>
</li>
<li>
<p><span class="code">-mnesia dump_log_load_regulation true | false</span>.
Controls if the log dumps should be performed as fast as
possible or if the dumper should do its own load
regulation. This feature is temporary and will disappear in a
future release. The default is <span class="code">false</span>.
</p>
</li>
<li>
<p><span class="code">-mnesia dump_log_update_in_place true | false</span>.
Controls if log dumps are performed on a copy of
the original data file, or if the log dump is
performed on the original data file. The default is <span class="code">true</span></p>
</li>
<li>
<p><span class="code">-mnesia dump_log_write_threshold Max</span>, where
<span class="code">Max</span> is an integer which specifies the maximum number of writes
allowed to the transaction log before a new dump of the log
is performed. It defaults to 100 log writes.
</p>
</li>
<li>
<p><span class="code">-mnesia dump_log_time_threshold Max</span>,
where <span class="code">Max</span> is an integer which
specifies the dump log interval in milliseconds. It defaults
to 3 minutes. If a dump has not been performed within
<span class="code">dump_log_time_threshold</span> milliseconds, then a new dump is
performed regardless of how many writes have been
performed.
</p>
</li>
<li>
<p><span class="code">-mnesia event_module Module</span>. The
name of the Mnesia event handler callback module. The default is
<span class="code">mnesia_event</span>.
</p>
</li>
<li>
<p><span class="code">-mnesia extra_db_nodes Nodes</span> specifies a list of
nodes, in addition to the ones found in the schema, with which
Mnesia should also establish contact. The default value
is the empty list <span class="code">[]</span>.
</p>
</li>
<li>
<p><span class="code">-mnesia fallback_error_function {UserModule, UserFunc}</span>
specifies a user supplied callback function
which will be called if a fallback is installed and mnesia
goes down on another node. Mnesia will call the function
with one argument the name of the dying node, e.g.
<span class="code">UserModule:UserFunc(DyingNode)</span>.
Mnesia should be restarted or else
the database could be inconsistent.
The default behaviour is to terminate mnesia.
</p>
</li>
<li>
<p><span class="code">-mnesia max_wait_for_decision Timeout</span>. Specifies
how long Mnesia will wait for other nodes to share their
knowledge regarding the outcome of an unclear transaction. By
default the <span class="code">Timeout</span> is set to the atom
<span class="code">infinity</span>, which implies that if Mnesia upon startup
encounters a "heavyweight transaction" whose outcome is
unclear, the local Mnesia will wait until Mnesia is started
on some (in worst cases all) of the other nodes that were
involved in the interrupted transaction. This is a very rare
situation, but when/if it happens, Mnesia does not guess if
the transaction on the other nodes was committed or aborted.
Mnesia will wait until it knows the outcome and then act
accordingly.
</p>
<p>If <span class="code">Timeout</span> is set to an integer value in
milliseconds, Mnesia will force "heavyweight transactions"
to be finished, even if the outcome of the transaction for
the moment is unclear. After <span class="code">Timeout</span> milliseconds,
Mnesia will commit/abort the transaction and continue with
the startup. This may lead to a situation where the
transaction is committed on some nodes and aborted on other
nodes. If the transaction was a schema transaction, the
inconsistency may be fatal.
</p>
</li>
<li>
<p><span class="code">-mnesia no_table_loaders NUMBER</span> specifies the number of
parallel table loaders during start. More loaders can be good if the
network latency is high or if many tables contains few records.
The default value is <span class="code">2</span>.
</p>
</li>
<li>
<p><span class="code">-mnesia send_compressed Level</span> specifies the level of
compression to be used when copying a table from the local node to
another one. The default level is 0.
</p>
<p><span class="code">Level</span> must be an integer in the interval [0, 9], with 0
representing no compression and 9 representing maximum compression.
Before setting it to a non-zero value, make sure the remote nodes
understand this configuration.
</p>
</li>
<li>
<p><span class="code">-mnesia schema_location Loc</span> controls where
Mnesia will look for its schema. The parameter
<span class="code">Loc</span> may be one of the following atoms: </p>
<dl>
<dt><strong><span class="code">disc</span></strong></dt>
<dd>
<p>Mandatory disc. The schema is assumed to be located
in the Mnesia directory. If the schema cannot be found,
Mnesia refuses to start. This is the old behavior.
</p>
</dd>
<dt><strong><span class="code">ram</span></strong></dt>
<dd>
<p>Mandatory RAM. The schema resides in RAM
only. At start-up, a tiny new schema is generated. This
default schema just contains the definition of the schema
table and only resides on the local node. Since no other
nodes are found in the default schema, the configuration
parameter <span class="code">extra_db_nodes</span> must be used in
order to let the
node share its table definitions with other nodes. (The
<span class="code">extra_db_nodes</span> parameter may also be used on disc based nodes.)
</p>
</dd>
<dt><strong><span class="code">opt_disc</span></strong></dt>
<dd>
<p>Optional disc. The schema may reside either on disc
or in RAM. If the schema is found on disc, Mnesia starts as a
disc based node and the storage type of the schema table is
<span class="code">disc_copies</span>. If no schema is found on disc, Mnesia starts
as a disc-less node and the storage type of the schema table is
<span class="code">ram_copies</span>. The default value for the application parameter
is <span class="code">opt_disc</span>.
</p>
</dd>
</dl>
</li>
</ul>
<p>First the SASL application parameters are checked, then
the command line flags are checked, and finally, the default
value is chosen.
</p>
</div>
<h3><a name="id86391">See Also</a></h3>
<div class="REFBODY">
<p>mnesia_registry(3), mnesia_session(3), qlc(3),
dets(3), ets(3), disk_log(3), application(3)
</p>
</div>
</div>
<div class="footer">
<hr>
<p>Copyright © 1997-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>
distrib
>
Fedora
>
17
>
i386
>
media
>
updates
>
by-pkgid
>
675c8c8167236dfcf8d66da674f931e8
>
files
>
1009
