👤
Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

Linux 2.6 - man page for mnesia (linux section 3erl)

mnesia(3erl)			     Erlang Module Definition			     mnesia(3erl)

NAME
       mnesia - A Distributed Telecommunications DBMS

DESCRIPTION
       Mnesia  is a distributed DataBase Management System (DBMS), appropriate for telecommunica-
       tions 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 appli-
	   cations.

	 * 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 loca-
	   tion of data.

	 * Extremely fast real time data searches.

	 * Schema manipulation routines. It is possible to reconfigure the DBMS at runtime  with-
	   out 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 def-
       initions.  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:  cur-
	   rently  '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 sev-
	   eral 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 prop-
	   erty  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 cer-
	   tain 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 posi-
	   tions 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 .

	 * 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 ta-
	   ble.

       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 mne-
       sia: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  mne-
       sia: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 check-
		  point.  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  mne-
		  sia: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  mini-
		  mized  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  check-
		  point  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 check-
		  point.  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 manip-
	      ulation 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 func-
		  tion 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 mne-
	      sia: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 struc-
	      ture 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 exam-
	      ple, 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 func-
	      tion calls performed in the Fun are mapped to the  corresponding	dirty  functions.
	      This  still  involves logging, replication and subscriptions, but there is no lock-
	      ing, local transaction storage, or commit protocols involved. Checkpoint	retainers
	      and  indices  are  updated,  but	they  will  be	updated dirty. As for normal mne-
	      sia:dirty_* operations, the operations are performed semi-asynchronously. See  mne-
	      sia: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  man-
	      ager is not involved and no locks are set. A dirty operation does, however, guaran-
	      tee 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 cer-
	      tain 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 transac-
	      tions 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  mne-
	      sia: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 mne-
	      sia: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  persis-
		  tent, 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.

       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 rec-
		  ommended, 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  ta-
		  ble  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.

		* {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 Snmp-
		  Struct . 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 map-
		  ping between the logical tables that make up an SNMP	control  application  and
		  the physical data which makes up a Mnesia table.

		* {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 over-
		  written. 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 trans-
	      action 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 func-
	      tion.

	      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 mne-
	      sia: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  mne-
	      sia: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, coun-
	      ters can never become less than zero. There are two significant differences between
	      this  function  and  the	action of first reading the record, performing the arith-
	      metics, 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  New-
	      Val 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  mne-
	      sia: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  mne-
	      sia: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  mne-
	      sia: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}, {mod-
	      ule, 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 call-
		  back	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 con-
		  figuration 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 set-
		  ting.  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  uninten-
		  tional  mixing  of  directories you may easily end up with a inconsistent data-
		  base, 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 ,  oth-
	      erwise 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,  mne-
	      sia: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 mne-
	      sia: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 dead-
	      lock. 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 toler-
		  ance	(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 '_' parame-
	      ter. 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. How-
	      ever, 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,  mne-
	      sia: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 . Cur-
	      rently, 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.

       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 enter-
	      ing a new interesting phase in its execution, it may be a good  idea  to	use  mne-
	      sia: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 oper-
		  ation  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 mne-
	      sia: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 mne-
	      sia: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 poten-
	      tially  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  Mas-
	      terNodes 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 configura-
	      tion 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 con-
	      venient to achieve this.

	      The SnmpStruct argument is a list of SNMP information. Currently, the only informa-
	      tion 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  tele-
	      phone 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  proto-
	      col.  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 man-
	      agers.

	      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 par-
	      ticipating  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  pos-
	      sible  to  add  and remove Mnesia nodes from the schema. The initial schema is nor-
	      mally 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 identi-
	      fier. 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 func-
	      tion 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 mne-
	      sia: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 mne-
	      sia: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  ele-
		  ment	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  config-
		  ured to be the activity access callback module.

		* auto_repair . This argument returns true or false to indicate if Mnesia is con-
		  figured to invoke the auto repair facility on corrupted disc files.

		* backup_module . This argument returns the name of the module which  is  config-
		  ured to be the backup callback module.

		* checkpoints . This argument returns a list of the names of the checkpoints cur-
		  rently 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 data-
		  base. 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 transac-
		  tion 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 trans-
		  action 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  transac-
		  tion 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 run-
		  ning_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  sub-
		  scribing 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. Call-
	      ing 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 mne-
		  sia:select/3 and mnesia:select/1 . The difference is that the match  specifica-
		  tion 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 speci-
		  fied in the schema.

		* checkpoints . This argument returns the names of the	currently  active  check-
		  points which involves this table on this node.

		* cookie  .  This argument returns a table cookie which is a unique system gener-
		  ated 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  ta-
		  ble.

		* 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  use-
		  ful 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 ta-
		  ble 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  cur-
		  rently 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 sub-
		  scribing 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 ta-
		  ble 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 var-
		  ious 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 transac-
	      tion.

	      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 trans-
	      action 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  fol-
	      lows:

	      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 dif-
	      ferent 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 func-
	      tion 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 ta-
	      ble.  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 deter-
	      mined 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  transac-
	      tion 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  fol-
	      lowing 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 auto-
	   matically 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  {mne-
	     sia_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 sub-
	     scribe 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 subscrib-
	     ing to updates in the schema table.

	   trace :
	     Activates all events at the level debug. On this debug level, the Mnesia event  han-
	     dler 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  per-
	   formed  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 call-
	   back 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  situa-
	   tion,  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 con-
	   tinue with the startup. This may lead to a situation where the transaction is  commit-
	   ted on some nodes and aborted on other nodes. If the transaction was a schema transac-
	   tion, 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 con-
	   tains few records. The default value is 2 .

	 * -mnesia send_compressed Level specifies the level of compression to be used when copy-
	   ing 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 param-
	   eter 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)

Ericsson AB				  mnesia 4.4.17 			     mnesia(3erl)


All times are GMT -4. The time now is 11:19 AM.

Unix & Linux Forums Content CopyrightŠ1993-2018. All Rights Reserved.
×
UNIX.COM Login
Username:
Password:  
Show Password