Provided by: erlang-manpages_16.b.3-dfsg-1ubuntu2.2_all 
NAME
mnesia - A Distributed Telecommunications DBMS
DESCRIPTION
Mnesia 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.
Listed below are some of the most important and attractive capabilities, Mnesia provides:
* A relational/object hybrid data model which is suitable for telecommunications
applications.
* A specifically designed DBMS query language, QLC (as an add-on library).
* Persistence. Tables may be coherently kept on disc as well as in main memory.
* Replication. Tables may be replicated at several nodes.
* Atomic transactions. A series of table manipulation operations can be grouped into a
single atomic transaction.
* Location transparency. Programs can be written without knowledge of the actual
location of data.
* Extremely fast real time data searches.
* Schema manipulation routines. It is possible to reconfigure the DBMS at runtime
without stopping the system.
This Reference Manual describes the Mnesia API. This includes functions used to define and
manipulate Mnesia tables.
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.
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:
* type. 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.
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.
* record_name. 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.
* ram_copies A table can be replicated on a number of Erlang nodes. The ram_copies
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.
* disc_copies The disc_copies 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 disc_copies 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.
* disc_only_copies Some, or all, table replicas can be kept on disc only. These replicas
are considerably slower than the RAM based replicas.
* index 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.
* local_content When an application requires tables whose contents is local to each
node, local_content 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 local_content field to true if you want to enable the
local_content behavior. The default is false.
* majority This attribute can be either true or false (default is false). When true, 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.
* snmp 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.
* attributes. The names of the attributes for the records that are inserted in the
table.
See mnesia:create_table/2 about the complete set of table properties and their details.
This document uses a table of persons to illustrate various examples. The following record
definition is assumed:
-record(person, {name,
age = 0,
address = unknown,
salary = 0,
children = []}),
The first attribute of the record is the primary key, or key for short.
The function descriptions are sorted in alphabetic order. Hint: start to read about
mnesia:create_table/2, mnesia:lock/2 and mnesia:activity/4 before you continue on and
learn about the rest.
Writing or deleting in transaction context creates a local copy of each modified record
during the transaction. During iteration, i.e. mnesia:fold[lr]/4 mnesia:next/2
mnesia:prev/2 mnesia:snmp_get_next_index/2, 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.
EXPORTS
abort(Reason) -> transaction abort
Makes the transaction silently return the tuple {aborted, Reason}. The abortion of
a Mnesia transaction means that an exception will be thrown to an enclosing catch.
Thus, the expression catch mnesia:abort(x) does not abort the transaction.
activate_checkpoint(Args) -> {ok,Name,Nodes} | {error,Reason}
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.
Args is a list of the following tuples:
* {name,Name}. Name 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.
* {max,MaxTabs}. MaxTabs 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 mnesia:add_table_copy/3, a retainer will also be attached
automatically.
* {min,MinTabs}. MinTabs 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.
* {allow_remote,Bool}. false means that all retainers must be local. The
checkpoint cannot be activated if a table does not reside locally. true allows
retainers to be allocated on any node. Default is set to true.
* {ram_overrides_dump,Bool}. Only applicable for ram_copies. Bool allows you to
choose to backup the table state as it is in RAM, or as it is on disc. true
means that the latest committed records in RAM should be included in the
checkpoint. These are the records that the application accesses. false 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 false.
Returns {ok,Name,Nodes} or {error,Reason}. Name is the (possibly generated) name of
the checkpoint. Nodes are the nodes that are involved in the checkpoint. Only nodes
that keep a checkpoint retainer know about the checkpoint.
activity(AccessContext, Fun [, Args]) -> ResultOfFun | exit(Reason)
Invokes mnesia:activity(AccessContext, Fun, Args, AccessMod) where AccessMod is the
default access callback module obtained by mnesia:system_info(access_module). Args
defaults to the empty list [].
activity(AccessContext, Fun, Args, AccessMod) -> ResultOfFun | exit(Reason)
This function executes the functional object Fun with the arguments Args.
The code which executes inside the activity can consist of a series of table
manipulation functions, which is performed in a AccessContext. Currently, the
following access contexts are supported:
transaction:
Short for {transaction, infinity}
{transaction, Retries}:
Invokes mnesia:transaction(Fun, Args, Retries). Note that the result from the
Fun is returned if the transaction was successful (atomic), otherwise the
function exits with an abort reason.
sync_transaction:
Short for {sync_transaction, infinity}
{sync_transaction, Retries}:
Invokes mnesia:sync_transaction(Fun, Args, Retries). Note that the result from
the Fun is returned if the transaction was successful (atomic), otherwise the
function exits with an abort reason.
async_dirty:
Invokes mnesia:async_dirty(Fun, Args).
sync_dirty:
Invokes mnesia:sync_dirty(Fun, Args).
ets:
Invokes mnesia:ets(Fun, Args).
This function (mnesia:activity/4) differs in an important aspect from the
mnesia:transaction, mnesia:sync_transaction, mnesia:async_dirty, mnesia:sync_dirty
and mnesia:ets functions. The AccessMod argument is the name of a callback module
which implements the mnesia_access behavior.
Mnesia will forward calls to the following functions:
* mnesia:lock/2 (read_lock_table/1, write_lock_table/1)
* mnesia:write/3 (write/1, s_write/1)
* mnesia:delete/3 (delete/1, s_delete/1)
* mnesia:delete_object/3 (delete_object/1, s_delete_object/1)
* mnesia:read/3 (read/1, wread/1)
* mnesia:match_object/3 (match_object/1)
* mnesia:all_keys/1
* mnesia:first/1
* mnesia:last/1
* mnesia:prev/2
* mnesia:next/2
* mnesia:index_match_object/4 (index_match_object/2)
* mnesia:index_read/3
* mnesia:table_info/2
to the corresponding:
* AccessMod:lock(ActivityId, Opaque, LockItem, LockKind)
* AccessMod:write(ActivityId, Opaque, Tab, Rec, LockKind)
* AccessMod:delete(ActivityId, Opaque, Tab, Key, LockKind)
* AccessMod:delete_object(ActivityId, Opaque, Tab, RecXS, LockKind)
* AccessMod:read(ActivityId, Opaque, Tab, Key, LockKind)
* AccessMod:match_object(ActivityId, Opaque, Tab, Pattern, LockKind)
* AccessMod:all_keys(ActivityId, Opaque, Tab, LockKind)
* AccessMod:first(ActivityId, Opaque, Tab)
* AccessMod:last(ActivityId, Opaque, Tab)
* AccessMod:prev(ActivityId, Opaque, Tab, Key)
* AccessMod:next(ActivityId, Opaque, Tab, Key)
* AccessMod:index_match_object(ActivityId, Opaque, Tab, Pattern, Attr, LockKind)
* AccessMod:index_read(ActivityId, Opaque, Tab, SecondaryKey, Attr, LockKind)
* AccessMod:table_info(ActivityId, Opaque, Tab, InfoItem)
where ActivityId is a record which represents the identity of the enclosing Mnesia
activity. The first field (obtained with element(1, ActivityId) contains an atom
which may be interpreted as the type of the activity: 'ets', 'async_dirty',
'sync_dirty' or 'tid'. 'tid' means that the activity is a transaction. The
structure of the rest of the identity record is internal to Mnesia.
Opaque is an opaque data structure which is internal to Mnesia.
add_table_copy(Tab, Node, Type) -> {aborted, R} | {atomic, ok}
This function makes another copy of a table at the node Node. The Type argument
must be either of the atoms ram_copies, disc_copies, or disc_only_copies. For
example, the following call ensures that a disc replica of the person table also
exists at node Node.
mnesia:add_table_copy(person, Node, disc_copies)
This function can also be used to add a replica of the table named schema.
add_table_index(Tab, AttrName) -> {aborted, R} | {atomic, ok}
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:
mnesia:add_table_index(person, age)
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.
all_keys(Tab) -> KeyList | transaction abort
This function returns a list of all keys in the table named Tab. The semantics of
this function is context sensitive. See mnesia:activity/4 for more information. In
transaction context it acquires a read lock on the entire table.
async_dirty(Fun, [, Args]) -> ResultOfFun | exit(Reason)
Call the Fun in a context which is not protected by a transaction. The Mnesia
function calls performed in the Fun 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
mnesia:activity/4 and the Mnesia User's Guide for more details.
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.
Note:It is more than 10 times more efficient to read records dirty than within a
transaction.
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.
Note: Calling (nesting) a mnesia:[a]sync_dirty inside a transaction context will
inherit the transaction semantics.
backup(Opaque [, BackupMod]) -> ok | {error,Reason}
Activates a new checkpoint covering all Mnesia tables, including the schema, with
maximum degree of redundancy and performs a backup using backup_checkpoint/2/3. The
default value of the backup callback module BackupMod is obtained by
mnesia:system_info(backup_module).
backup_checkpoint(Name, Opaque [, BackupMod]) -> ok | {error,Reason}
The tables are backed up to external media using the backup module BackupMod.
Tables with the local contents property is being backed up as they exist on the
current node. BackupMod is the default backup callback module obtained by
mnesia:system_info(backup_module). See the User's Guide about the exact callback
interface (the mnesia_backup behavior).
change_config(Config, Value) -> {error, Reason} | {ok, ReturnValue}
The Config should be an atom of the following configuration parameters:
extra_db_nodes:
Value is a list of nodes which Mnesia should try to connect to. The ReturnValue
will be those nodes in Value that Mnesia are connected to.
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.
Note: Mnesia may be connected to other nodes than those returned in
ReturnValue.
dc_dump_limit:
Value is a number. See description in Configuration Parameters below. The
ReturnValue is the new value. Note this configuration parameter is not
persistent, it will be lost when mnesia stopped.
change_table_access_mode(Tab, AccessMode) -> {aborted, R} | {atomic, ok}
The AcccessMode is by default the atom read_write but it may also be set to the
atom read_only. If the AccessMode is set to read_only, it means that it is not
possible to perform updates to the table. At startup Mnesia always loads read_only
tables locally regardless of when and if Mnesia was terminated on other nodes.
change_table_copy_type(Tab, Node, To) -> {aborted, R} | {atomic, ok}
For example:
mnesia:change_table_copy_type(person, node(), disc_copies)
Transforms our person table from a RAM table into a disc based table at Node.
This function can also be used to change the storage type of the table named
schema. The schema table can only have ram_copies or disc_copies as the storage
type. If the storage type of the schema is ram_copies, no other table can be disc
resident on that node.
change_table_load_order(Tab, LoadOrder) -> {aborted, R} | {atomic, ok}
The LoadOrder priority is by default 0 (zero) but may be set to any integer. The
tables with the highest LoadOrder priority will be loaded first at startup.
change_table_majority(Tab, Majority) -> {aborted, R} | {atomic, ok}
Majority must be a boolean; the default is false. When true, a majority of the
table's replicas must be available for an update to succeed. When used on
fragmented tables, Tab must be the name base table. Directly changing the majority
setting on individual fragments is not allowed.
clear_table(Tab) -> {aborted, R} | {atomic, ok}
Deletes all entries in the table Tab.
create_schema(DiscNodes) -> ok | {error,Reason}
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.
mnesia:create_schema/1 fails if any of the Erlang nodes given as DiscNodes are not
alive, if Mnesia is running on anyone of the nodes, or if anyone of the nodes
already has a schema. Use mnesia:delete_schema/1 to get rid of old faulty schemas.
Note: Only nodes with disc should be included in DiscNodes. Disc-less nodes, that
is nodes where all tables including the schema only resides in RAM, may not be
included.
create_table(Name, TabDef) -> {atomic, ok} | {aborted, Reason}
This function creates a Mnesia table called Name according to the argument TabDef.
This list must be a list of {Item, Value} tuples, where the following values are
allowed:
* {access_mode, Atom}. The access mode is by default the atom read_write but it
may also be set to the atom read_only. If the AccessMode is set to read_only,
it means that it is not possible to perform updates to the table.
At startup Mnesia always loads read_only 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.
* {attributes, AtomList} a list of the attribute names for the records that are
supposed to populate the table. The default value is [key, val]. The table must
have at least one extra attribute in addition to the key.
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
record_info(fields, RecordName) instead. It can be used for records of type
RecordName
* {disc_copies, Nodelist}, where Nodelist is a list of the nodes where this table
is supposed to have disc copies. If a table replica is of type disc_copies, all
write operations on this particular replica of the table are written to disc as
well as to the RAM copy of the table.
It is possible to have a replicated table of type disc_copies on one node, and
another type on another node. The default value is []
* {disc_only_copies, Nodelist}, where Nodelist is a list of the nodes where this
table is supposed to have disc_only_copies. 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.
* {index, Intlist}, where Intlist is a list of attribute names (atoms) or record
fields for which Mnesia shall build and maintain an extra index table. The qlc
query compiler may or may not utilize any additional indices while processing
queries on a table.
* {load_order, Integer}. The load order priority is by default 0 (zero) but may
be set to any integer. The tables with the highest load order priority will be
loaded first at startup.
* {majority, Flag}, where Flag must be a boolean. If true, 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.
* {ram_copies, Nodelist}, where Nodelist is a list of the nodes where this table
is supposed to have RAM copies. A table replica of type ram_copies is obviously
not written to disc on a per transaction basis. It is possible to dump
ram_copies replicas to disc with the function mnesia:dump_tables(Tabs). The
default value for this attribute is [node()].
* {record_name, Name}, where Name 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.
* {snmp, SnmpStruct}. See mnesia:snmp_open_table/2 for a description of
SnmpStruct. If this attribute is present in the ArgList to
mnesia:create_table/2, 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.
* {storage_properties, [{Backend, Properties}]. Forwards additional properties to
the backend storage. Backend can currently be ets or dets and Properties is a
list of options sent to the backend storage during table creation. Properties
may not contain properties already used by mnesia such as type or named_table.
For example:
mnesia:create_table(table, [{ram_copies, [node()]}, {disc_only_copies, nodes()},
{storage_properties,
[{ets, [compressed]}, {dets, [{auto_save, 5000}]} ]}])
* {type, Type}, where Type must be either of the atoms set, ordered_set or bag.
The default value is set. In a set all records have unique keys and in a bag
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'.
* {local_content, Bool}, where Bool must be either true or false. The default
value is false.
For example, the following call creates the person table previously defined and
replicates it on 2 nodes:
mnesia:create_table(person,
[{ram_copies, [N1, N2]},
{attributes, record_info(fields,person)}]).
If it was required that Mnesia build and maintain an extra index table on the
address attribute of all the person records that are inserted in the table, the
following code would be issued:
mnesia:create_table(person,
[{ram_copies, [N1, N2]},
{index, [address]},
{attributes, record_info(fields,person)}]).
The specification of index and attributes may be hard coded as {index, [2]} and
{attributes, [name, age, address, salary, children]} respectively.
mnesia:create_table/2 writes records into the schema 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.
deactivate_checkpoint(Name) -> ok | {error, Reason}
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. Name is the
name of an active checkpoint.
del_table_copy(Tab, Node) -> {aborted, R} | {atomic, ok}
Deletes the replica of table Tab at node Node. When the last replica is deleted
with this function, the table disappears entirely.
This function may also be used to delete a replica of the table named schema. Then
the mnesia node will be removed. Note: Mnesia must be stopped on the node first.
del_table_index(Tab, AttrName) -> {aborted, R} | {atomic, ok}
This function deletes the index on attribute with name AttrName in a table.
delete({Tab, Key}) -> transaction abort | ok
Invokes mnesia:delete(Tab, Key, write)
delete(Tab, Key, LockKind) -> transaction abort | ok
Deletes all records in table Tab with the key Key.
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires a lock of type LockKind in the
record. Currently the lock types write and sticky_write are supported.
delete_object(Record) -> transaction abort | ok
Invokes mnesia:delete_object(Tab, Record, write) where Tab is element(1, Record).
delete_object(Tab, Record, LockKind) -> transaction abort | ok
If a table is of type bag, we may sometimes want to delete only some of the records
with a certain key. This can be done with the delete_object/3 function. A complete
record must be supplied to this function.
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires a lock of type LockKind on the
record. Currently the lock types write and sticky_write are supported.
delete_schema(DiscNodes) -> ok | {error,Reason}
Deletes a database created with mnesia:create_schema/1. mnesia:delete_schema/1
fails if any of the Erlang nodes given as DiscNodes is not alive, or if Mnesia is
running on any of the nodes.
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 schema_location is
set.
Warning:
This function must be used with extreme caution since it makes existing persistent
data obsolete. Think twice before using it.
delete_table(Tab) -> {aborted, Reason} | {atomic, ok}
Permanently deletes all replicas of table Tab.
dirty_all_keys(Tab) -> KeyList | exit({aborted, Reason}).
This is the dirty equivalent of the mnesia:all_keys/1 function.
dirty_delete({Tab, Key}) -> ok | exit({aborted, Reason})
Invokes mnesia:dirty_delete(Tab, Key).
dirty_delete(Tab, Key) -> ok | exit({aborted, Reason})
This is the dirty equivalent of the mnesia:delete/3 function.
dirty_delete_object(Record)
Invokes mnesia:dirty_delete_object(Tab, Record) where Tab is element(1, Record).
dirty_delete_object(Tab, Record)
This is the dirty equivalent of the mnesia:delete_object/3 function.
dirty_first(Tab) -> Key | exit({aborted, Reason})
Records in set or bag 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 mnesia:dirty_next/2
function.
If there are no records at all in the table, this function returns the atom
'$end_of_table'. For this reason, it is highly undesirable, but not disallowed, to
use this atom as the key for any user records.
dirty_index_match_object(Pattern, Pos)
Invokes mnesia:dirty_index_match_object(Tab, Pattern, Pos) where Tab is element(1,
Pattern).
dirty_index_match_object(Tab, Pattern, Pos)
This is the dirty equivalent of the mnesia:index_match_object/4 function.
dirty_index_read(Tab, SecondaryKey, Pos)
This is the dirty equivalent of the mnesia:index_read/3 function.
dirty_last(Tab) -> Key | exit({aborted, Reason})
This function works exactly like mnesia:dirty_first/1 but returns the last object
in Erlang term order for the ordered_set table type. For all other table types,
mnesia:dirty_first/1 and mnesia:dirty_last/1 are synonyms.
dirty_match_object(Pattern) -> RecordList | exit({aborted, Reason}).
Invokes mnesia:dirty_match_object(Tab, Pattern) where Tab is element(1, Pattern).
dirty_match_object(Tab, Pattern) -> RecordList | exit({aborted, Reason}).
This is the dirty equivalent of the mnesia:match_object/3 function.
dirty_next(Tab, Key) -> Key | exit({aborted, Reason})
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
'$end_of_table' 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
mnesia:dirty_next/2 function.
dirty_prev(Tab, Key) -> Key | exit({aborted, Reason})
This function works exactly like mnesia:dirty_next/2 but returns the previous
object in Erlang term order for the ordered_set table type. For all other table
types, mnesia:dirty_next/2 and mnesia:dirty_prev/2 are synonyms.
dirty_read({Tab, Key}) -> ValueList | exit({aborted, Reason}
Invokes mnesia:dirty_read(Tab, Key).
dirty_read(Tab, Key) -> ValueList | exit({aborted, Reason}
This is the dirty equivalent of the mnesia:read/3 function.
dirty_select(Tab, MatchSpec) -> ValueList | exit({aborted, Reason}
This is the dirty equivalent of the mnesia:select/2 function.
dirty_slot(Tab, Slot) -> RecordList | exit({aborted, Reason})
This function can be used to traverse a table in a manner similar to the
mnesia:dirty_next/2 function. A table has a number of slots which range from 0
(zero) to some unknown upper bound. The function mnesia:dirty_slot/2 returns the
special atom '$end_of_table' 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.
dirty_update_counter({Tab, Key}, Incr) -> NewVal | exit({aborted, Reason})
Invokes mnesia:dirty_update_counter(Tab, Key, Incr).
dirty_update_counter(Tab, Key, Incr) -> NewVal | exit({aborted, Reason})
There are no special counter records in Mnesia. However, records of the form {Tab,
Key, Integer} can be used as (possibly disc resident) counters, when Tab is a set.
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:
* It is much more efficient
* mnesia:dirty_update_counter/3 is performed as an atomic operation despite the
fact that it is not protected by a transaction.
If two processes perform mnesia:dirty_update_counter/3 simultaneously, both updates
will take effect without the risk of losing one of the updates. The new value
NewVal of the counter is returned.
If Key don't exits, a new record is created with the value Incr if it is larger
than 0, otherwise it is set to 0.
dirty_write(Record) -> ok | exit({aborted, Reason})
Invokes mnesia:dirty_write(Tab, Record) where Tab is element(1, Record).
dirty_write(Tab, Record) -> ok | exit({aborted, Reason})
This is the dirty equivalent of mnesia:write/3.
dump_log() -> dumped
Performs a user initiated dump of the local log file. This is usually not necessary
since Mnesia, by default, manages this automatically.
dump_tables(TabList) -> {atomic, ok} | {aborted, Reason}
This function dumps a set of ram_copies 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.
dump_to_textfile(Filename)
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
mnesia:load_textfile/1. Only use this function for educational purposes. Use other
functions to deal with real backups.
error_description(Error) -> String
All Mnesia transactions, including all the schema update functions, either return
the value {atomic, Val} or the tuple {aborted, Reason}. The Reason can be either of
the following atoms. The error_description/1 function returns a descriptive string
which describes the error.
* nested_transaction. Nested transactions are not allowed in this context.
* badarg. Bad or invalid argument, possibly bad type.
* no_transaction. Operation not allowed outside transactions.
* combine_error. Table options were illegally combined.
* bad_index. Index already exists or was out of bounds.
* already_exists. Schema option is already set.
* index_exists. Some operations cannot be performed on tabs with index.
* no_exists. Tried to perform operation on non-existing, or not alive, item.
* system_limit. Some system_limit was exhausted.
* mnesia_down. A transaction involving records at some remote node which died
while transaction was executing. Record(s) are no longer available elsewhere in
the network.
* not_a_db_node. A node which does not exist in the schema was mentioned.
* bad_type. Bad type on some arguments.
* node_not_running. Node not running.
* truncated_binary_file. Truncated binary in file.
* active. Some delete operations require that all active records are removed.
* illegal. Operation not supported on record.
The Error may be Reason, {error, Reason}, or {aborted, Reason}. The Reason may be
an atom or a tuple with Reason as an atom in the first field.
ets(Fun, [, Args]) -> ResultOfFun | exit(Reason)
Call the Fun in a raw context which is not protected by a transaction. The Mnesia
function call is performed in the Fun are performed directly on the local ets
tables on the assumption that the local storage type is ram_copies 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
disc_copies tables if all operations are read only. See mnesia:activity/4 and the
Mnesia User's Guide for more details.
Note: Calling (nesting) a mnesia:ets inside a transaction context will inherit the
transaction semantics.
first(Tab) -> Key | transaction abort
Records in set or bag 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 mnesia:next/2 function.
If there are no records at all in the table, this function returns the atom
'$end_of_table'. For this reason, it is highly undesirable, but not disallowed, to
use this atom as the key for any user records.
foldl(Function, Acc, Table) -> NewAcc | transaction abort
Iterates over the table Table and calls Function(Record, NewAcc) for each Record in
the table. The term returned from Function will be used as the second argument in
the next call to the Function.
foldl returns the same term as the last call to Function returned.
foldr(Function, Acc, Table) -> NewAcc | transaction abort
This function works exactly like foldl/3 but iterates the table in the opposite
order for the ordered_set table type. For all other table types, foldr/3 and
foldl/3 are synonyms.
force_load_table(Tab) -> yes | ErrorDescription
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.
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.
index_match_object(Pattern, Pos) -> transaction abort | ObjList
Invokes mnesia:index_match_object(Tab, Pattern, Pos, read) where Tab is element(1,
Pattern).
index_match_object(Tab, Pattern, Pos, LockKind) -> transaction abort | ObjList
In a manner similar to the mnesia:index_read/3 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 mnesia:match_object/3 function with the exception that
this function requires the following conditions:
* The table Tab must have an index on position Pos.
* The element in position Pos in Pattern must be bound. Pos may either be an
integer (#record.Field), or an attribute name.
The two index search functions described here are automatically invoked when
searching tables with qlc list comprehensions and also when using the low level
mnesia:[dirty_]match_object functions.
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires a lock of type LockKind on the
entire table or on a single record. Currently, the lock type read is supported.
index_read(Tab, SecondaryKey, Pos) -> transaction abort | RecordList
Assume there is an index on position Pos 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 person table, the call
mnesia:index_read(person, 36, #person.age) returns a list of all persons with age
equal to 36. Pos may also be an attribute name (atom), but if the notation
mnesia:index_read(person, 36, age) is used, the field position will be searched for
in runtime, for each call.
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires a read lock on the entire table.
info() -> ok
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.
install_fallback(Opaque) -> ok | {error,Reason}
Invokes mnesia:install_fallback(Opaque, Args) where Args is [{scope, global}].
install_fallback(Opaque), BackupMod) -> ok | {error,Reason}
Invokes mnesia:install_fallback(Opaque, Args) where Args is [{scope, global},
{module, BackupMod}].
install_fallback(Opaque, Args) -> ok | {error,Reason}
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.
Args is a list of the following tuples:
* {module, BackupMod}. All accesses of the backup media is performed via a
callback module named BackupMod. The Opaque argument is forwarded to the
callback module which may interpret it as it wish. The default callback module
is called mnesia_backup and it interprets the Opaque argument as a local
filename. The default for this module is also configurable via the -mnesia
mnesia_backup configuration parameter.
* {scope, Scope} The Scope of a fallback may either be global for the entire
database or local 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.
If the Scope of the operation is local the fallback will only be installed on
the local node.
* {mnesia_dir, AlternateDir} This argument is only valid if the scope of the
installation is local. Normally the installation of a fallback is targeted
towards the Mnesia directory as configured with the -mnesia dir configuration
parameter. But by explicitly supplying an AlternateDir 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.
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.
is_transaction() -> boolean
When this function is executed inside a transaction context it returns true,
otherwise false.
last(Tab) -> Key | transaction abort
This function works exactly like mnesia:first/1 but returns the last object in
Erlang term order for the ordered_set table type. For all other table types,
mnesia:first/1 and mnesia:last/1 are synonyms.
load_textfile(Filename)
Loads a series of definitions and data found in the text file (generated with
mnesia:dump_to_textfile/1) 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.
lock(LockItem, LockKind) -> Nodes | ok | transaction abort
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.
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 ok if it was a read
lock.
This function mnesia:lock/2 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 LockKind's are supported:
write:
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.
read:
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.
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 retries is not reached.
See mnesia:transaction/3 for the details.
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:
sticky_write:
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.
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.
Currently, two kinds of LockItem's are supported by this function:
{table, Tab}:
This acquires a lock of type LockKind on the entire table Tab.
{global, GlobalKey, Nodes}:
This acquires a lock of type LockKind on the global resource GlobalKey. The
lock is acquired on all active nodes in the Nodes list.
Locks are released when the outermost transaction ends.
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires locks otherwise it just ignores the
request.
match_object(Pattern) ->transaction abort | RecList
Invokes mnesia:match_object(Tab, Pattern, read) where Tab is element(1, Pattern).
match_object(Tab, Pattern, LockKind) ->transaction abort | RecList
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.
For example, the call mnesia:match_object(person, {person, '_', 36, '_', '_'},
read) returns a list of all person records with an age field of thirty-six (36).
The function mnesia:match_object/3 automatically uses indices if these exist.
However, no heuristics are performed in order to select the best index.
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires a lock of type LockKind on the
entire table or a single record. Currently, the lock type read is supported.
move_table_copy(Tab, From, To) -> {aborted, Reason} | {atomic, ok}
Moves the copy of table Tab from node From to node To.
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.
This function cannot be used on local_content tables.
next(Tab, Key) -> Key | transaction abort
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
'$end_of_table' is returned. Otherwise, the function returns a key which can be
used to read the actual record.
prev(Tab, Key) -> Key | transaction abort
This function works exactly like mnesia:next/2 but returns the previous object in
Erlang term order for the ordered_set table type. For all other table types,
mnesia:next/2 and mnesia:prev/2 are synonyms.
read({Tab, Key}) -> transaction abort | RecordList
Invokes mnesia:read(Tab, Key, read).
read(Tab, Key) -> transaction abort | RecordList
Invokes mnesia:read(Tab, Key, read).
read(Tab, Key, LockKind) -> transaction abort | RecordList
This function reads all records from table Tab with key Key. This function has the
same semantics regardless of the location of Tab. If the table is of type bag, the
mnesia:read(Tab, Key) can return an arbitrarily long list. If the table is of type
set, the list is either of length 1, or [].
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires a lock of type LockKind. Currently,
the lock types read, write and sticky_write are supported.
If the user wants to update the record it is more efficient to use
write/sticky_write 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.
read_lock_table(Tab) -> ok | transaction abort
Invokes mnesia:lock({table, Tab}, read).
report_event(Event) -> ok
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.
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
mnesia:report_event/1. The Event may be any term and generates a {mnesia_user,
Event} event for any processes that subscribe to Mnesia system events.
restore(Opaque, Args) -> {atomic, RestoredTabs} |{aborted, Reason}
With this function, tables may be restored online from a backup without restarting
Mnesia. Opaque is forwarded to the backup module. Args is a list of the following
tuples:
* {module,BackupMod} The backup module BackupMod will be used to access the
backup media. If omitted, the default backup module will be used.
* {skip_tables, TabList} Where TabList is a list of tables which should not be
read from the backup.
* {clear_tables, TabList} Where TabList 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.
* {keep_tables, TabList} Where TabList 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.
* {recreate_tables, TabList} Where TabList 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.
* {default_op, Operation} Where Operation is one of the following operations
skip_tables, clear_tables, keep_tables or recreate_tables. 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
clear_tables will be used.
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.
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.
s_delete({Tab, Key}) -> ok | transaction abort
Invokes mnesia:delete(Tab, Key, sticky_write)
s_delete_object(Record) -> ok | transaction abort
Invokes mnesia:delete_object(Tab, Record, sticky_write) where Tab is element(1,
Record).
s_write(Record) -> ok | transaction abort
Invokes mnesia:write(Tab, Record, sticky_write) where Tab is element(1, Record).
schema() -> ok
Prints information about all table definitions on the tty.
schema(Tab) -> ok
Prints information about one table definition on the tty.
select(Tab, MatchSpec [, Lock]) -> transaction abort | [Object]
Matches the objects in the table Tab using a match_spec as described in the ERTS
Users Guide. Optionally a lock read or write can be given as the third argument,
default is read. The return value depends on the MatchSpec.
Note: for best performance select should be used before any modifying operations
are done on that table in the same transaction, i.e. don't use write or delete
before a select.
In its simplest forms the match_spec's look like this:
* MatchSpec = [MatchFunction]
* MatchFunction = {MatchHead, [Guard], [Result]}
* MatchHead = tuple() | record()
* Guard = {"Guardtest name", ...}
* Result = "Term construct"
See the ERTS Users Guide and ets documentation for a complete description of the
select.
For example to find the names of all male persons with an age over 30 in table Tab
do:
MatchHead = #person{name='$1', sex=male, age='$2', _='_'},
Guard = {'>', '$2', 30},
Result = '$1',
mnesia:select(Tab,[{MatchHead, [Guard], [Result]}]),
select(Tab, MatchSpec, NObjects, Lock) -> transaction abort | {[Object],Cont} |
'$end_of_table'
Matches the objects in the table Tab 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 NObjects argument. The lock argument can be read
or write. The continuation should be used as argument to mnesia:select/1, if more
or all answers are needed.
Note: for best performance select should be used before any modifying operations
are done on that table in the same transaction, i.e. don't use mnesia:write or
mnesia:delete before a mnesia:select. For efficiency the NObjects is a
recommendation only and the result may contain anything from an empty list to all
available results.
select(Cont) -> transaction abort | {[Object],Cont} | '$end_of_table'
Selects more objects with the match specification initiated by mnesia:select/4.
Note: Any modifying operations, i.e. mnesia:write or mnesia:delete, that are done
between the mnesia:select/4 and mnesia:select/1 calls will not be visible in the
result.
set_debug_level(Level) -> OldLevel
Changes the internal debug level of Mnesia. See the chapter about configuration
parameters for details.
set_master_nodes(MasterNodes) -> ok | {error, Reason}
For each table Mnesia will determine its replica nodes (TabNodes) and invoke
mnesia:set_master_nodes(Tab, TabMasterNodes) where TabMasterNodes is the
intersection of MasterNodes and TabNodes. See mnesia:set_master_nodes/2 about the
semantics.
set_master_nodes(Tab, MasterNodes) -> ok | {error, Reason}
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 mnesia:set_master_nodes(Tab, MasterNodes) 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
MasterNodes may only contain nodes where the table has a replica and if the
MasterNodes 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.
The master node setting is always local and it may be changed regardless of whether
Mnesia is started or not.
The database may also become inconsistent if the max_wait_for_decision
configuration parameter is used or if mnesia:force_load_table/1 is used.
snmp_close_table(Tab) -> {aborted, R} | {atomic, ok}
Removes the possibility for SNMP to manipulate the table.
snmp_get_mnesia_key(Tab, RowIndex) -> {ok, Key} | undefined
Types:
Tab ::= atom()
RowIndex ::= [integer()]
Key ::= key() | {key(), key(), ...}
key() ::= integer() | string() | [integer()]
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.
snmp_get_next_index(Tab, RowIndex) -> {ok, NextIndex} | endOfTable
Types:
Tab ::= atom()
RowIndex ::= [integer()]
NextIndex ::= [integer()]
The RowIndex may specify a non-existing row. Specifically, it might be the empty
list. Returns the index of the next lexicographical row. If RowIndex is the empty
list, this function will return the index of the first row in the table.
snmp_get_row(Tab, RowIndex) -> {ok, Row} | undefined
Types:
Tab ::= atom()
RowIndex ::= [integer()]
Row ::= record(Tab)
Makes it possible to read a row by its SNMP index. This index is specified as an
SNMP OBJECT IDENTIFIER, a list of integers.
snmp_open_table(Tab, SnmpStruct) -> {aborted, R} | {atomic, ok}
Types:
Tab ::= atom()
SnmpStruct ::= [{key, type()}]
type() ::= type_spec() | {type_spec(), type_spec(), ...}
type_spec() ::= fix_string | string | integer
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.
The SnmpStruct 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
fix_string. This means that a string has fixed size. For example:
mnesia:snmp_open_table(person, [{key, string}])
causes the person table to be ordered as an SNMP table.
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:
mnesia:create_table(employee,
[{snmp, [{key, {integer, string}}]},
{attributes, record_info(fields, employees)}]),
The corresponding SNMP table would have three columns; department, name and telno.
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 department and name only. The
application could then use the telno column internally, but it would not be visible
to the SNMP managers.
In a table monitored by SNMP, all elements must be integers, strings, or lists of
integers.
When a table is SNMP ordered, modifications are more expensive than usual, O(logN).
And more memory is used.
Note:Only the lexicographical SNMP ordering is implemented in Mnesia, not the
actual SNMP monitoring.
start() -> ok | {error, Reason}
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 mnesia:create_schema/1 and the Mnesia
User's Guide for more information about disc-less nodes.
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 mnesia:create_schema/1. 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.
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.
The schema file, as well as all other files which Mnesia needs, are kept in the
Mnesia directory. The command line option -mnesia dir Dir 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 Mnesia.Node.
application:start(mnesia) may also be used.
stop() -> stopped
Stops Mnesia locally on the current node.
application:stop(mnesia) may also be used.
subscribe(EventCategory)
Ensures that a copy of all events of type EventCategory are sent to the caller. The
event types available are described in the Mnesia User's Guide.
sync_dirty(Fun, [, Args]) -> ResultOfFun | exit(Reason)
Call the Fun in a context which is not protected by a transaction. The Mnesia
function calls performed in the Fun are mapped to the corresponding dirty
functions. It is performed in almost the same context as mnesia:async_dirty/1,2.
The difference is that the operations are performed synchronously. The caller waits
for the updates to be performed on all active replicas before the Fun returns. See
mnesia:activity/4 and the Mnesia User's Guide for more details.
sync_transaction(Fun, [[, Args], Retries]) -> {aborted, Reason} | {atomic, ResultOfFun}
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
mnesia:transaction/[1,2,3].
This functionality can be used to avoid that one process may overload a database on
another node.
system_info(InfoKey) -> Info | exit({aborted, Reason})
Returns information about the Mnesia system, such as transaction statistics,
db_nodes, and configuration parameters. Valid keys are:
* all. This argument returns a list of all local system information. Each element
is a {InfoKey, InfoVal} tuples.Note: New InfoKey's may be added and old
undocumented InfoKey's may be removed without notice.
* access_module. This argument returns the name of the module which is configured
to be the activity access callback module.
* auto_repair. This argument returns true or false to indicate if Mnesia is
configured to invoke the auto repair facility on corrupted disc files.
* backup_module. This argument returns the name of the module which is configured
to be the backup callback module.
* checkpoints. This argument returns a list of the names of the checkpoints
currently active on this node.
* event_module. This argument returns the name of the module which is the event
handler callback module.
* db_nodes. 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 mnesia:add_table_copy/3. The
function can be invoked even if Mnesia is not yet running.
* debug. This argument returns the current debug level of Mnesia.
* directory. This argument returns the name of the Mnesia directory. It can be
invoked even if Mnesia is not yet running.
* dump_log_load_regulation. 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.
* dump_log_time_threshold. This argument returns the time threshold for
transaction log dumps in milliseconds.
* dump_log_update_in_place. 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.
* dump_log_write_threshold. This argument returns the write threshold for
transaction log dumps as the number of writes to the transaction log.
* extra_db_nodes. This argument returns a list of extra db_nodes to be contacted
at start-up.
* fallback_activated. This argument returns true if a fallback is activated,
otherwise false.
* held_locks. This argument returns a list of all locks held by the local Mnesia
lock manager.
* is_running. This argument returns yes or no to indicate if Mnesia is running.
It may also return starting or stopping. Can be invoked even if Mnesia is not
yet running.
* local_tables. This argument returns a list of all tables which are configured
to reside locally.
* lock_queue. This argument returns a list of all transactions that are queued
for execution by the local lock manager.
* log_version. This argument returns the version number of the Mnesia transaction
log format.
* master_node_tables. This argument returns a list of all tables with at least
one master node.
* protocol_version. This argument returns the version number of the Mnesia inter-
process communication protocol.
* running_db_nodes. 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 db_nodes and extra_db_nodes 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
running_db_nodes. 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 running_db_nodes list than all db_nodes and
extra_db_nodes together.
* schema_location. This argument returns the initial schema location.
* subscribers. This argument returns a list of local processes currently
subscribing to system events.
* tables. This argument returns a list of all locally known tables.
* transactions. This argument returns a list of all currently active local
transactions.
* transaction_failures. This argument returns a number which indicates how many
transactions have failed since Mnesia was started.
* transaction_commits. This argument returns a number which indicates how many
transactions have terminated successfully since Mnesia was started.
* transaction_restarts. This argument returns a number which indicates how many
transactions have been restarted since Mnesia was started.
* transaction_log_writes. This argument returns a number which indicates the
number of write operation that have been performed to the transaction log since
start-up.
* use_dir. 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.
* version. This argument returns the current version number of Mnesia.
table(Tab [,[Option]]) -> QueryHandle
Returns a QLC (Query List Comprehension) query handle, see qlc(3erl).The module qlc
implements a query language, it can use mnesia tables as sources of data. Calling
mnesia:table/1,2 is the means to make the mnesia table Tab usable to QLC.
The list of Options may contain mnesia options or QLC options, the following
options are recognized by Mnesia: {traverse, SelectMethod},{lock,
Lock},{n_objects,Number}, any other option is forwarded to QLC. The lock option may
be read or write, default is read. The option n_objects 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 100 objects at a time are
returned. The option traverse determines the method to traverse the whole table (if
needed), the default method is select:
* select. The table is traversed by calling mnesia:select/4 and mnesia:select/1.
The match specification (the second argument of select/3) 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 select/3
given a match specification that matches all objects.
* {select, MatchSpec}. As for select the table is traversed by calling
mnesia:select/3 and mnesia:select/1. 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.
table_info(Tab, InfoKey) -> Info | exit({aborted, Reason})
The table_info/2 function takes two arguments. The first is the name of a Mnesia
table, the second is one of the following keys:
* all. This argument returns a list of all local table information. Each element
is a {InfoKey, ItemVal} tuples. Note: New InfoItem's may be added and old
undocumented InfoItem's may be removed without notice.
* access_mode. This argument returns the access mode of the table. The access
mode may either be read_only or read_write.
* arity. This argument returns the arity of records in the table as specified in
the schema.
* attributes. This argument returns the table attribute names which are specified
in the schema.
* checkpoints. This argument returns the names of the currently active
checkpoints which involves this table on this node.
* cookie. 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.
* disc_copies. This argument returns the nodes where a disc_copy of the table
resides according to the schema.
* disc_only_copies . This argument returns the nodes where a disc_only_copy of
the table resides according to the schema.
* index. This argument returns the list of index position integers for the table.
* load_node. 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.
* load_order. This argument returns the load order priority of the table. It is
an integer and defaults to 0 (zero).
* load_reason. 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.
* local_content. This argument returns true or false to indicate whether the
table is configured to have locally unique content on each node.
* master_nodes. This argument returns the master nodes of a table.
* memory. This argument returns the number of words allocated to the table on
this node.
* ram_copies. This argument returns the nodes where a ram_copy of the table
resides according to the schema.
* record_name. This argument returns the record name, common for all records in
the table
* size. This argument returns the number of records inserted in the table.
* snmp. This argument returns the SNMP struct. []meaning that the table currently
has no SNMP properties.
* storage_type.This argument returns the local storage type of the table. It can
be disc_copies, ram_copies, disc_only_copies, or the atom unknown. unknown is
returned for all tables which only reside remotely.
* subscribers. This argument returns a list of local processes currently
subscribing to local table events which involve this table on this node.
* type. This argument returns the table type, which is either bag, set or
ordered_set..
* user_properties. This argument returns the user associated table properties of
the table. It is a list of the stored property records.
* version. 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.
* where_to_read.This argument returns the node where the table can be read. If
the value nowhere is returned, the table is not loaded, or it resides at a
remote node which is not running.
* where_to_write. This argument returns a list of the nodes that currently hold
an active replica of the table.
* wild_pattern. 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 '_'.
transaction(Fun [[, Args], Retries]) -> {aborted, Reason} | {atomic, ResultOfFun}
This function executes the functional object Fun with arguments Args as a
transaction.
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 transaction/1 returns the tuple {aborted, Reason}.
If all is well, {atomic, ResultOfFun} is returned where ResultOfFun is the value of
the last expression in Fun.
A function which adds a family to the database can be written as follows if we have
a structure {family, Father, Mother, ChildrenList}:
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)}.
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 'EXIT' signal while executing the family
code, the transaction aborts. Accordingly, the situation where half a family is
added can never occur.
It is also useful to update the database within a transaction if several processes
concurrently update the same records. For example, the function raise(Name,
Amount), which adds Amount to the salary field of a person, should be implemented
as follows:
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).
When this function executes within a transaction, several processes running on
different nodes can concurrently execute the raise/2 function without interfering
with each other.
Since Mnesia detects deadlocks, a transaction can be restarted any number of times.
This function will attempt a restart as specified in Retries. Retries must be an
integer greater than 0 or the atom infinity. Default is infinity.
transform_table(Tab, Fun, NewAttributeList, NewRecordName) -> {aborted, R} | {atomic, ok}
This function applies the argument Fun to all records in the table. Fun is a
function which takes a record of the old type and returns a transformed record of
the new type. The Fun argument can also be the atom ignore, it indicates that only
the meta data about the table will be updated. Usage of ignore is not recommended
but included as a possibility for the user do to his own transform.
NewAttributeList and NewRecordName 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.
mnesia:write/3 will work but mnesia:write/1 will not.
transform_table(Tab, Fun, NewAttributeList) -> {aborted, R} | {atomic, ok}
Invokes mnesia:transform_table(Tab, Fun, NewAttributeList, RecName) where RecName
is mnesia:table_info(Tab, record_name).
traverse_backup(Source, [SourceMod,] Target, [TargetMod,] Fun, Acc) -> {ok, LastAcc} |
{error, Reason}
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.
* SourceMod and TargetMod are the names of the modules which actually access the
backup media.
* Source and Target are opaque data used exclusively by the modules SourceMod and
TargetMod for the purpose of initializing the backup media.
* Acc is an initial accumulator value.
* Fun(BackupItems, Acc) is applied to each item in the backup. The Fun must
return a tuple {BackupItems,NewAcc}, where BackupItems is a list of valid
backup items, and NewAcc is a new accumulator value. The returned backup items
are written in the target backup.
* LastAcc is the last accumulator value. This is the last NewAcc value that was
returned by Fun.
uninstall_fallback() -> ok | {error,Reason}
Invokes mnesia:uninstall_fallback([{scope, global}]).
uninstall_fallback(Args) -> ok | {error,Reason}
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.
Args is a list of the following tuples:
* {module, BackupMod}. See mnesia:install_fallback/2 about the semantics.
* {scope, Scope} See mnesia:install_fallback/2 about the semantics.
* {mnesia_dir, AlternateDir} See mnesia:install_fallback/2 about the semantics.
unsubscribe(EventCategory)
Stops sending events of type EventCategory to the caller.
wait_for_tables(TabList,Timeout) -> ok | {timeout, BadTabList} | {error, Reason}
Some applications need to wait for certain tables to be accessible in order to do
useful work. mnesia:wait_for_tables/2 hangs until all tables in the TabList are
accessible, or until timeout is reached.
wread({Tab, Key}) -> transaction abort | RecordList
Invoke mnesia:read(Tab, Key, write).
write(Record) -> transaction abort | ok
Invoke mnesia:write(Tab, Record, write) where Tab is element(1, Record).
write(Tab, Record, LockKind) -> transaction abort | ok
Writes the record Record to the table Tab.
The function returns ok, or aborts if an error occurs. For example, the transaction
aborts if no person table exists.
The semantics of this function is context sensitive. See mnesia:activity/4 for more
information. In transaction context it acquires a lock of type LockKind. The
following lock types are supported: write and sticky_write.
write_lock_table(Tab) -> ok | transaction abort
Invokes mnesia:lock({table, Tab}, write).
CONFIGURATION PARAMETERS
Mnesia reads the following application configuration parameters:
* -mnesia access_module Module. The name of the Mnesia activity access callback module.
The default is mnesia.
* -mnesia auto_repair true | false. This flag controls whether Mnesia will try to
automatically repair files that have not been properly closed. The default is true.
* -mnesia backup_module Module. The name of the Mnesia backup callback module. The
default is mnesia_backup.
* -mnesia debug Level Controls the debug level of Mnesia. Possible values are:
none:
No trace outputs at all. This is the default setting.
verbose:
Activates tracing of important debug events. These debug events generate
{mnesia_info, Format, Args} system events. Processes may subscribe to these events
with mnesia:subscribe/1. The events are always sent to Mnesia's event handler.
debug:
Activates all events at the verbose level plus full trace of all debug events. These
debug events generate {mnesia_info, Format, Args} system events. Processes may
subscribe to these events with mnesia:subscribe/1. 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.
trace:
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.
false:
An alias for none.
true:
An alias for debug.
* -mnesia core_dir Directory. 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.
* -mnesia dc_dump_limit Number. Controls how often disc_copies tables are dumped from
memory. Tables are dumped when filesize(Log) > (filesize(Tab)/Dc_dump_limit). Lower
values reduces cpu overhead but increases disk space and startup times. The default is
4.
* -mnesia dir Directory. 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.
* -mnesia dump_log_load_regulation true | false. 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 false.
* -mnesia dump_log_update_in_place true | false. 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 true
* -mnesia dump_log_write_threshold Max, where Max 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.
* -mnesia dump_log_time_threshold Max, where Max is an integer which specifies the dump
log interval in milliseconds. It defaults to 3 minutes. If a dump has not been
performed within dump_log_time_threshold milliseconds, then a new dump is performed
regardless of how many writes have been performed.
* -mnesia event_module Module. The name of the Mnesia event handler callback module. The
default is mnesia_event.
* -mnesia extra_db_nodes Nodes 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 [].
* -mnesia fallback_error_function {UserModule, UserFunc} 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. UserModule:UserFunc(DyingNode). Mnesia should be restarted or else the
database could be inconsistent. The default behaviour is to terminate mnesia.
* -mnesia max_wait_for_decision Timeout. Specifies how long Mnesia will wait for other
nodes to share their knowledge regarding the outcome of an unclear transaction. By
default the Timeout is set to the atom infinity, 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.
If Timeout 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 Timeout 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.
* -mnesia no_table_loaders NUMBER 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 2.
* -mnesia send_compressed Level specifies the level of compression to be used when
copying a table from the local node to another one. The default level is 0.
Level 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.
* -mnesia schema_location Loc controls where Mnesia will look for its schema. The
parameter Loc may be one of the following atoms:
disc:
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.
ram:
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 extra_db_nodes must be used in order to let the
node share its table definitions with other nodes. (The extra_db_nodes parameter may
also be used on disc based nodes.)
opt_disc:
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 disc_copies. If no schema is found on disc, Mnesia starts as a disc-less
node and the storage type of the schema table is ram_copies. The default value for
the application parameter is opt_disc.
First the SASL application parameters are checked, then the command line flags are
checked, and finally, the default value is chosen.
SEE ALSO
mnesia_registry(3erl), mnesia_session(3erl), qlc(3erl), dets(3erl), ets(3erl),
disk_log(3erl), application(3erl)