*

In the current implementation, every object insert and look-up operation results in a copy of the object.

*

'$end_of_table' is not to be used as a key, as this atom is used to mark the end of the table when using functions first/1 and next/2.

*

Two Erlang terms match if they are of the same type and have the same value, so that 1 matches 1, but not 1.0 (as 1.0 is a float() and not an integer()).

*

Two Erlang terms compare equal if they either are of the same type and value, or if both are numeric types and extend to the same value, so that 1 compares equal to both 1 and 1.0.

*

The ordered_set works on the Erlang term order and no defined order exists between an integer() and a float() that extends to the same value. Hence the key 1 and the key 1.0 are regarded as equal in an ordered_set table.

badarg:

If any argument has the wrong format.

badarg:

If the table identifier is invalid.

badarg:

If the operation is denied because of table access rights (protected or private).

system_limit:

Modification of a value causes it to not be representable internally in the VM. For example, incrementation of a counter past the largest integer representable.

system_limit:

If a match specification passed as argument has excessive nesting which causes scheduler stack exhaustion for the scheduler that the calling process is executing on. Scheduler stack size can be configured when starting the runtime system.

*

Single-step traversal one key at at time, using first/1, next/2, last/1 and prev/2.

*

Search with simple match patterns, using match/1/2/3, match_delete/2 and match_object/1/2/3.

*

Search with more powerful match specifications, using select/1/2/3, select_count/2, select_delete/2, select_replace/2 and select_reverse/1/2/3.

*

Table conversions, using tab2file/2/3 and tab2list/1.

*

Any key may be missed.

*

Any key may be found more than once.

*

The traversal may fail with badarg exception if keys are deleted.

*

the table is of type ordered_set.

*

the entire table traversal is done within one ETS function call.

*

function safe_fixtable/2 is used to keep the table fixated during the entire traversal.

Opaque continuation used by select/1,3, select_reverse/1,3, match/1,3, and match_object/1,3.

A match specification, see above.

A compiled match specification.

A table identifier, as returned by new/2.

Types:

Returns a list of all tables at the node. Named tables are specified by their names, unnamed tables are specified by their table identifiers.

There is no guarantee of consistency in the returned list. Tables created or deleted by other processes "during" the ets:all() call either are or are not included in the list. Only tables created/deleted before ets:all() is called are guaranteed to be included/excluded.

Types:

Deletes the entire table Tab.

Types:

Deletes all objects with key Key from table Tab.

Types:

Delete all objects in the ETS table Tab. The operation is guaranteed to be atomic and isolated.

Types:

Delete the exact object Object from the ETS table, leaving objects with the same key but other differences (useful for type bag). In a duplicate_bag table, all instances of the object are deleted.

Types:

Reads a file produced by tab2file/2 or tab2file/3 and creates the corresponding table Tab.

Equivalent to file2tab(Filename, []).

Types:

Reads a file produced by tab2file/2 or tab2file/3 and creates the corresponding table Tab.

The only supported option is {verify,boolean()}. If verification is turned on (by specifying {verify,true}), the function uses whatever information is present in the file to assert that the information is not damaged. How this is done depends on which extended_info was written using tab2file/3.

If no extended_info is present in the file and {verify,true} is specified, the number of objects written is compared to the size of the original table when the dump was started. This can make verification fail if the table was public and objects were added or removed while the table was dumped to file. To avoid this problem, either do not verify files dumped while updated simultaneously or use option {extended_info, [object_count]} to tab2file/3, which extends the information in the file with the number of objects written.

If verification is turned on and the file was written with option {extended_info, [md5sum]}, reading the file is slower and consumes radically more CPU time than otherwise.

{verify,false} is the default.

Types:

Returns the first key Key in table Tab. For an ordered_set table, the first key in Erlang term order is returned. For other table types, the first key according to the internal order of the table is returned. If the table is empty, '$end_of_table' is returned.

To find subsequent keys in the table, use next/2.

Types:

Acc0 is returned if the table is empty. This function is similar to lists:foldl/3. The table elements are traversed in an unspecified order, except for ordered_set tables, where they are traversed first to last.

If Function inserts objects into the table, or another process inserts objects into the table, those objects can (depending on key ordering) be included in the traversal.

Types:

Acc0 is returned if the table is empty. This function is similar to lists:foldr/3. The table elements are traversed in an unspecified order, except for ordered_set tables, where they are traversed last to first.

If Function inserts objects into the table, or another process inserts objects into the table, those objects can (depending on key ordering) be included in the traversal.

Types:

Fills an already created ETS table with the objects in the already opened Dets table DetsTab. Existing objects in the ETS table are kept unless overwritten.

If any of the tables does not exist or the Dets table is not open, a badarg exception is raised.

Types:

Pseudo function that by a parse_transform translates LiteralFun typed as parameter in the function call to a match specification. With "literal" is meant that the fun must textually be written as the parameter of the function, it cannot be held in a variable that in turn is passed to the function.

The parse transform is provided in the ms_transform module and the source must include file ms_transform.hrl in STDLIB for this pseudo function to work. Failing to include the hrl file in the source results in a runtime error, not a compile time error. The include file is easiest included by adding line -include_lib("stdlib/include/ms_transform.hrl"). to the source file.

The fun is very restricted, it can take only a single parameter (the object to match): a sole variable or a tuple. It must use the is_ guard tests. Language constructs that have no representation in a match specification (if, case, receive, and so on) are not allowed.

The return value is the resulting match specification.

Example:

1> ets:fun2ms(fun({M,N}) when N > 3 -> M end).
[{{'$1','$2'},[{'>','$2',3}],['$1']}]

Variables from the environment can be imported, so that the following works:

2> X=3.
3
3> ets:fun2ms(fun({M,N}) when N > X -> M end).
[{{'$1','$2'},[{'>','$2',{const,3}}],['$1']}]

The imported variables are replaced by match specification const expressions, which is consistent with the static scoping for Erlang funs. However, local or global function calls cannot be in the guard or body of the fun. Calls to built-in match specification functions is of course allowed:

4> ets:fun2ms(fun({M,N}) when N > X, my_fun(M) -> M end).
Error: fun containing local Erlang function calls
('my_fun' called in guard) cannot be translated into match_spec
{error,transform_error}
5> ets:fun2ms(fun({M,N}) when N > X, is_atom(M) -> M end).
[{{'$1','$2'},[{'>','$2',{const,3}},{is_atom,'$1'}],['$1']}]

As shown by the example, the function can be called from the shell also. The fun must be literally in the call when used from the shell as well.

For more information, see ms_transform(3erl).

Types:

Make process Pid the new owner of table Tab. If successful, message {'ETS-TRANSFER',Tab,FromPid,GiftData} is sent to the new owner.

The process Pid must be alive, local, and not already the owner of the table. The calling process must be the table owner.

Notice that this function does not affect option heir of the table. A table owner can, for example, set heir to itself, give the table away, and then get it back if the receiver terminates.

Displays information about all ETS tables on a terminal.

Types:

Browses table Tab on a terminal.

Types:

Returns information about table Tab as a list of tuples. If Tab has the correct type for a table identifier, but does not refer to an existing ETS table, undefined is returned. If Tab is not of the correct type, a badarg exception is raised.

Types:

Returns the information associated with Item for table Tab, or returns undefined if Tab does not refer an existing ETS table. If Tab is not of the correct type, or if Item is not one of the allowed values, a badarg exception is raised.

In addition to the {Item,Value} pairs defined for info/1, the following items are allowed:

Types:

Replaces the existing objects of table Tab with objects created by calling the input function InitFun, see below. This function is provided for compatibility with the dets module, it is not more efficient than filling a table by using insert/2.

When called with argument read, the function InitFun is assumed to return end_of_input when there is no more input, or {Objects, Fun}, where Objects is a list of objects and Fun is a new input function. Any other value Value is returned as an error {error, {init_fun, Value}}. Each input function is called exactly once, and if an error occur, the last function is called with argument close, the reply of which is ignored.

If the table type is set and more than one object exists with a given key, one of the objects is chosen. This is not necessarily the last object with the given key in the sequence of objects returned by the input functions. This holds also for duplicated objects stored in tables of type bag.

Types:

Inserts the object or all of the objects in list ObjectOrObjects into table Tab.

The entire operation is guaranteed to be atomic and isolated, even when a list of objects is inserted.

Types:

Same as insert/2 except that instead of overwriting objects with the same key (for set or ordered_set) or adding more objects with keys already existing in the table (for bag and duplicate_bag), false is returned.

If ObjectOrObjects is a list, the function checks every key before inserting anything. Nothing is inserted unless all keys present in the list are absent from the table. Like insert/2, the entire operation is guaranteed to be atomic and isolated.

Types:

Checks if a term represent a valid compiled match specification. A compiled match specifications is only valid on the Erlang node where it was compiled by calling match_spec_compile/1.

After STDLIB 3.4 (OTP 20.0) compiled match specifications have an external representation as a node specific reference to the original compiled match specification. If passed through binary_to_term(term_to_binary(CMS)) or sent to another node and back, the result may or may not be a valid compiled match specification depending on if the original compiled match specification was still alive.

Types:

Returns the last key Key according to Erlang term order in table Tab of type ordered_set. For other table types, the function is synonymous to first/1. If the table is empty, '$end_of_table' is returned.

To find preceding keys in the table, use prev/2.

Types:

Returns a list of all objects with key Key in table Tab.

The difference is the same as between =:= and ==.

As an example, one can insert an object with integer() 1 as a key in an ordered_set and get the object returned as a result of doing a lookup/2 with float() 1.0 as the key to search for.

For tables of type set or ordered_set, the function returns either the empty list or a list with one element, as there cannot be more than one object with the same key. For tables of type bag or duplicate_bag, the function returns a list of arbitrary length.

Notice that the time order of object insertions is preserved; the first object inserted with the specified key is the first in the resulting list, and so on.

Insert and lookup times in tables of type set, bag, and duplicate_bag are constant, regardless of the table size. For the ordered_set datatype, time is proportional to the (binary) logarithm of the number of objects.

Types:

For a table Tab of type set or ordered_set, the function returns the Pos:th element of the object with key Key.

For tables of type bag or duplicate_bag, the functions returns a list with the Pos:th element of every object with key Key.

If no object with key Key exists, the function exits with reason badarg.

The difference between set, bag, and duplicate_bag on one hand, and ordered_set on the other, regarding the fact that ordered_set view keys as equal when they compare equal whereas the other table types regard them equal only when they match, holds for lookup_element/3.

Types:

Continues a match started with match/3. The next chunk of the size specified in the initial match/3 call is returned together with a new Continuation, which can be used in subsequent calls to this function.

When there are no more objects in the table, '$end_of_table' is returned.

Types:

Matches the objects in table Tab against pattern Pattern.

A pattern is a term that can contain:

The function returns a list with one element for each matching object, where each element is an ordered list of pattern variable bindings, for example:

6> ets:match(T, '$1'). % Matches every object in table
[[{rufsen,dog,7}],[{brunte,horse,5}],[{ludde,dog,5}]]
7> ets:match(T, {'_',dog,'$1'}).
[[7],[5]]
8> ets:match(T, {'_',cow,'$1'}).
[]

If the key is specified in the pattern, the match is very efficient. If the key is not specified, that is, if it is a variable or an underscore, the entire table must be searched. The search time can be substantial if the table is very large.

For tables of type ordered_set, the result is in the same order as in a first/next traversal.

Types:

Works like match/2, but returns only a limited (Limit) number of matching objects. Term Continuation can then be used in subsequent calls to match/1 to get the next chunk of matching objects. This is a space-efficient way to work on objects in a table, which is faster than traversing the table object by object using first/1 and next/2.

If the table is empty, '$end_of_table' is returned.

Use safe_fixtable/2 to guarantee safe traversal for subsequent calls to match/1.

Types:

Deletes all objects that match pattern Pattern from table Tab. For a description of patterns, see match/2.

Types:

Continues a match started with match_object/3. The next chunk of the size specified in the initial match_object/3 call is returned together with a new Continuation, which can be used in subsequent calls to this function.

When there are no more objects in the table, '$end_of_table' is returned.

Types:

Matches the objects in table Tab against pattern Pattern. For a description of patterns, see match/2. The function returns a list of all objects that match the pattern.

If the key is specified in the pattern, the match is very efficient. If the key is not specified, that is, if it is a variable or an underscore, the entire table must be searched. The search time can be substantial if the table is very large.

For tables of type ordered_set, the result is in the same order as in a first/next traversal.

Types:

Works like match_object/2, but only returns a limited (Limit) number of matching objects. Term Continuation can then be used in subsequent calls to match_object/1 to get the next chunk of matching objects. This is a space-efficient way to work on objects in a table, which is faster than traversing the table object by object using first/1 and next/2.

If the table is empty, '$end_of_table' is returned.

Use safe_fixtable/2 to guarantee safe traversal for subsequent calls to match_object/1.

Types:

Transforms a match specification into an internal representation that can be used in subsequent calls to match_spec_run/2. The internal representation is opaque. To check the validity of a compiled match specification, use is_compiled_ms/1.

If term MatchSpec does not represent a valid match specification, a badarg exception is raised.

Types:

Executes the matching specified in a compiled match specification on a list of terms. Term CompiledMatchSpec is to be the result of a call to match_spec_compile/1 and is hence the internal representation of the match specification one wants to use.

The matching is executed on each element in List and the function returns a list containing all results. If an element in List does not match, nothing is returned for that element. The length of the result list is therefore equal or less than the length of parameter List.

Example:

The following two calls give the same result (but certainly not the same execution time):

Table = ets:new...
MatchSpec = ...
% The following call...
ets:match_spec_run(ets:tab2list(Table),


                   ets:match_spec_compile(MatchSpec)),
% ...gives the same result as the more common (and more efficient)
ets:select(Table, MatchSpec),

Types:

Works like lookup/2, but does not return the objects. Returns true if one or more elements in the table has key Key, otherwise false.

Types:

Creates a new table and returns a table identifier that can be used in subsequent operations. The table identifier can be sent to other processes so that a table can be shared between different processes within a node.

Parameter Options is a list of options that specifies table type, access rights, key position, and whether the table is named. Default values are used for omitted options. This means that not specifying any options ([]) is the same as specifying [set, protected, {keypos,1}, {heir,none}, {write_concurrency,false}, {read_concurrency,false}, {decentralized_counters,false}].

Types:

Returns the next key Key2, following key Key1 in table Tab. For table type ordered_set, the next key in Erlang term order is returned. For other table types, the next key according to the internal order of the table is returned. If no next key exists, '$end_of_table' is returned.

To find the first key in the table, use first/1.

Unless a table of type set, bag, or duplicate_bag is fixated using safe_fixtable/2, a call to next/2 will fail if Key1 no longer exists in the table. For table type ordered_set, the function always returns the next key after Key1 in term order, regardless whether Key1 ever existed in the table.

Types:

Returns the previous key Key2, preceding key Key1 according to Erlang term order in table Tab of type ordered_set. For other table types, the function is synonymous to next/2. If no previous key exists, '$end_of_table' is returned.

To find the last key in an ordered_set table, use last/1.

Types:

Renames the named table Tab to the new name Name. Afterwards, the old name cannot be used to access the table. Renaming an unnamed table has no effect.

Types:

Restores an opaque continuation returned by select/3 or select/1 if the continuation has passed through external term format (been sent between nodes or stored on disk).

The reason for this function is that continuation terms contain compiled match specifications and may therefore be invalidated if converted to external term format. Given that the original match specification is kept intact, the continuation can be restored, meaning it can once again be used in subsequent select/1 calls even though it has been stored on disk or on another node.

Examples:

The following sequence of calls may fail:

T=ets:new(x,[]),
...
MS = ets:fun2ms(fun({N,_}=A) when (N rem 10) =:= 0 -> A end),
{_,C} = ets:select(T, MS, 10),
MaybeBroken = binary_to_term(term_to_binary(C)),
ets:select(MaybeBroken).

The following sequence works, as the call to repair_continuation/2 reestablishes the MaybeBroken continuation.

T=ets:new(x,[]),
...
MS = ets:fun2ms(fun({N,_}=A) when (N rem 10) =:= 0 -> A end),
{_,C} = ets:select(T,MS,10),
MaybeBroken = binary_to_term(term_to_binary(C)),
ets:select(ets:repair_continuation(MaybeBroken,MS)).

The actual behavior of compiled match specifications when recreated from external format has changed and may change in future releases, but this interface remains for backward compatibility. See is_compiled_ms/1.

Types:

Fixes a table of type set, bag, or duplicate_bag for safe traversal using first/1 & next/2, match/3 & match/1, match_object/3 & match_object/1, or select/3 & select/1.

A process fixes a table by calling safe_fixtable(Tab, true). The table remains fixed until the process releases it by calling safe_fixtable(Tab, false), or until the process terminates.

If many processes fix a table, the table remains fixed until all processes have released it (or terminated). A reference counter is kept on a per process basis, and N consecutive fixes requires N releases to release the table.

When a table is fixed, a sequence of first/1 and next/2 calls are guaranteed to succeed even if keys are removed during the traversal. The keys for objects inserted or deleted during a traversal may or may not be returned by next/2 depending on the ordering of keys within the table and if the key exists at the time next/2 is called.

Example:

clean_all_with_value(Tab,X) ->


    safe_fixtable(Tab,true),


    clean_all_with_value(Tab,X,ets:first(Tab)),


    safe_fixtable(Tab,false).
clean_all_with_value(Tab,X,'$end_of_table') ->


    true;
clean_all_with_value(Tab,X,Key) ->


    case ets:lookup(Tab,Key) of


        [{Key,X}] ->


            ets:delete(Tab,Key);


        _ ->


            true


    end,


    clean_all_with_value(Tab,X,ets:next(Tab,Key)).

Notice that deleted objects are not freed from a fixed table until it has been released. If a process fixes a table but never releases it, the memory used by the deleted objects is never freed. The performance of operations on the table also degrades significantly.

To retrieve information about which processes have fixed which tables, use info(Tab, safe_fixed_monotonic_time). A system with many processes fixing tables can need a monitor that sends alarms when tables have been fixed for too long.

Notice that safe_fixtable/2 is not necessary for table type ordered_set and for traversals done by a single ETS function call, like select/2.

Types:

Continues a match started with select/3. The next chunk of the size specified in the initial select/3 call is returned together with a new Continuation, which can be used in subsequent calls to this function.

When there are no more objects in the table, '$end_of_table' is returned.

Types:

Matches the objects in table Tab using a match specification. This is a more general call than match/2 and match_object/2 calls. In its simplest form, the match specification is as follows:

MatchSpec = [MatchFunction]
MatchFunction = {MatchHead, [Guard], [Result]}
MatchHead = "Pattern as in ets:match"
Guard = {"Guardtest name", ...}
Result = "Term construct"

This means that the match specification is always a list of one or more tuples (of arity 3). The first element of the tuple is to be a pattern as described in match/2. The second element of the tuple is to be a list of 0 or more guard tests (described below). The third element of the tuple is to be a list containing a description of the value to return. In almost all normal cases, the list contains exactly one term that fully describes the value to return for each object.

The return value is constructed using the "match variables" bound in MatchHead or using the special match variables '$_' (the whole matching object) and '$$' (all match variables in a list), so that the following match/2 expression:

ets:match(Tab,{'$1','$2','$3'})

is exactly equivalent to:

ets:select(Tab,[{{'$1','$2','$3'},[],['$$']}])

And that the following match_object/2 call:

ets:match_object(Tab,{'$1','$2','$1'})

is exactly equivalent to

ets:select(Tab,[{{'$1','$2','$1'},[],['$_']}])

Composite terms can be constructed in the Result part either by simply writing a list, so that the following code:

ets:select(Tab,[{{'$1','$2','$3'},[],['$$']}])

gives the same output as:

ets:select(Tab,[{{'$1','$2','$3'},[],[['$1','$2','$3']]}])

That is, all the bound variables in the match head as a list. If tuples are to be constructed, one has to write a tuple of arity 1 where the single element in the tuple is the tuple one wants to construct (as an ordinary tuple can be mistaken for a Guard).

Therefore the following call:

ets:select(Tab,[{{'$1','$2','$1'},[],['$_']}])

gives the same output as:

ets:select(Tab,[{{'$1','$2','$1'},[],[{{'$1','$2','$3'}}]}])

This syntax is equivalent to the syntax used in the trace patterns (see the dbg(3erl)) module in Runtime_Tools.

The Guards are constructed as tuples, where the first element is the test name and the remaining elements are the test parameters. To check for a specific type (say a list) of the element bound to the match variable '$1', one would write the test as {is_list, '$1'}. If the test fails, the object in the table does not match and the next MatchFunction (if any) is tried. Most guard tests present in Erlang can be used, but only the new versions prefixed is_ are allowed (is_float, is_atom, and so on).

The Guard section can also contain logic and arithmetic operations, which are written with the same syntax as the guard tests (prefix notation), so that the following guard test written in Erlang:

is_integer(X), is_integer(Y), X + Y < 4711

is expressed as follows (X replaced with '$1' and Y with '$2'):

[{is_integer, '$1'}, {is_integer, '$2'}, {'<', {'+', '$1', '$2'}, 4711}]

For tables of type ordered_set, objects are visited in the same order as in a first/next traversal. This means that the match specification is executed against objects with keys in the first/next order and the corresponding result list is in the order of that execution.

Types:

Works like select/2, but only returns a limited (Limit) number of matching objects. Term Continuation can then be used in subsequent calls to select/1 to get the next chunk of matching objects. This is a space-efficient way to work on objects in a table, which is still faster than traversing the table object by object using first/1 and next/2.

If the table is empty, '$end_of_table' is returned.

Use safe_fixtable/2 to guarantee safe traversal for subsequent calls to select/1.

Types:

Matches the objects in table Tab using a match specification. If the match specification returns true for an object, that object considered a match and is counted. For any other result from the match specification the object is not considered a match and is therefore not counted.

This function can be described as a match_delete/2 function that does not delete any elements, but only counts them.

The function returns the number of objects matched.

Types:

Matches the objects in table Tab using a match specification. If the match specification returns true for an object, that object is removed from the table. For any other result from the match specification the object is retained. This is a more general call than the match_delete/2 call.

The function returns the number of objects deleted from the table.

Types:

Matches the objects in the table Tab using a match specification. For each matched object, the existing object is replaced with the match specification result.

The match-and-replace operation for each individual object is guaranteed to be atomic and isolated. The select_replace table traversal as a whole, like all other select functions, does not give such guarantees.

The match specifiction must be guaranteed to retain the key of any matched object. If not, select_replace will fail with badarg without updating any objects.

For the moment, due to performance and semantic constraints, tables of type bag are not yet supported.

The function returns the total number of replaced objects.

Example

For all 2-tuples with a list in second position, add atom 'marker' first in the list:

1> T = ets:new(x,[]), ets:insert(T, {key, [1, 2, 3]}).
true
2> MS = ets:fun2ms(fun({K, L}) when is_list(L) -> {K, [marker | L]} end).
[{{'$1','$2'},[{is_list,'$2'}],[{{'$1',[marker|'$2']}}]}]
3> ets:select_replace(T, MS).
1
4> ets:tab2list(T).
[{key,[marker,1,2,3]}]
	

A generic single object compare-and-swap operation:

[Old] = ets:lookup(T, Key),
New = update_object(Old),
Success = (1 =:= ets:select_replace(T, [{Old, [], [{const, New}]}])),
	

Types:

Continues a match started with select_reverse/3. For tables of type ordered_set, the traversal of the table continues to objects with keys earlier in the Erlang term order. The returned list also contains objects with keys in reverse order. For all other table types, the behavior is exactly that of select/1.

Example:

1> T = ets:new(x,[ordered_set]).
2> [ ets:insert(T,{N}) || N <- lists:seq(1,10) ].
...
3> {R0,C0} = ets:select_reverse(T,[{'_',[],['$_']}],4).
...
4> R0.
[{10},{9},{8},{7}]
5> {R1,C1} = ets:select_reverse(C0).
...
6> R1.
[{6},{5},{4},{3}]
7> {R2,C2} = ets:select_reverse(C1).
...
8> R2.
[{2},{1}]
9> '$end_of_table' = ets:select_reverse(C2).
...

Types:

Works like select/2, but returns the list in reverse order for table type ordered_set. For all other table types, the return value is identical to that of select/2.

Types:

Works like select/3, but for table type ordered_set traversing is done starting at the last object in Erlang term order and moves to the first. For all other table types, the return value is identical to that of select/3.

Notice that this is not equivalent to reversing the result list of a select/3 call, as the result list is not only reversed, but also contains the last Limit matching objects in the table, not the first.

Types:

Sets table options. The only allowed option to be set after the table has been created is heir. The calling process must be the table owner.

Types:

This function is mostly for debugging purposes, Normally first/next or last/prev are to be used instead.

Returns all objects in slot I of table Tab. A table can be traversed by repeatedly calling the function, starting with the first slot I=0 and ending when '$end_of_table' is returned. If argument I is out of range, the function fails with reason badarg.

Unless a table of type set, bag, or duplicate_bag is protected using safe_fixtable/2, a traversal can fail if concurrent updates are made to the table. For table type ordered_set, the function returns a list containing object I in Erlang term order.

Types:

Dumps table Tab to file Filename.

Equivalent to tab2file(Tab, Filename,[])

Types:

Dumps table Tab to file Filename.

When dumping the table, some information about the table is dumped to a header at the beginning of the dump. This information contains data about the table type, name, protection, size, version, and if it is a named table. It also contains notes about what extended information is added to the file, which can be a count of the objects in the file or a MD5 sum of the header and records in the file.

The size field in the header might not correspond to the number of records in the file if the table is public and records are added or removed from the table during dumping. Public tables updated during dump, and that one wants to verify when reading, needs at least one field of extended information for the read verification process to be reliable later.

Option extended_info specifies what extra information is written to the table dump:

Whenever option extended_info is used, it results in a file not readable by versions of ETS before that in STDLIB 1.15.1

If option sync is set to true, it ensures that the content of the file is written to the disk before tab2file returns. Defaults to {sync, false}.

Types:

Returns a list of all objects in table Tab.

Types:

Returns information about the table dumped to file by tab2file/2 or tab2file/3.

The following items are returned:

An error is returned if the file is inaccessible, badly damaged, or not produced with tab2file/2 or tab2file/3.

Types:

Returns a Query List Comprehension (QLC) query handle. The qlc module provides a query language aimed mainly at Mnesia, but ETS tables, Dets tables, and lists are also recognized by QLC as sources of data. Calling table/1,2 is the means to make the ETS table Tab usable to QLC.

When there are only simple restrictions on the key position, QLC uses lookup/2 to look up the keys. When that is not possible, the whole table is traversed. Option traverse determines how this is done:

Examples:

An explicit match specification is here used to traverse the table:

9> true = ets:insert(Tab = ets:new(t, []), [{1,a},{2,b},{3,c},{4,d}]),
MS = ets:fun2ms(fun({X,Y}) when (X > 1) or (X < 5) -> {Y} end),
QH1 = ets:table(Tab, [{traverse, {select, MS}}]).

An example with an implicit match specification:

10> QH2 = qlc:q([{Y} || {X,Y} <- ets:table(Tab), (X > 1) or (X < 5)]).

The latter example is equivalent to the former, which can be verified using function qlc:info/1:

11> qlc:info(QH1) =:= qlc:info(QH2).
true

qlc:info/1 returns information about a query handle, and in this case identical information is returned for the two query handles.

Types:

Returns and removes a list of all objects with key Key in table Tab.

The specified Key is used to identify the object by either comparing equal the key of an object in an ordered_set table, or matching in other types of tables (for details on the difference, see lookup/2 and new/2).

Types:

This function is a utility to test a match specification used in calls to select/2. The function both tests MatchSpec for "syntactic" correctness and runs the match specification against object Tuple.

If the match specification is syntactically correct, the function either returns {ok,Result}, where Result is what would have been the result in a real select/2 call, or false if the match specification does not match object Tuple.

If the match specification contains errors, tuple {error, Errors} is returned, where Errors is a list of natural language descriptions of what was wrong with the match specification.

This is a useful debugging and test tool, especially when writing complicated select/2 calls.

See also: erlang:match_spec_test/3.

Types:

Fills an already created/opened Dets table with the objects in the already opened ETS table named Tab. The Dets table is emptied before the objects are inserted.

Types:

This function provides an efficient way to update one or more counters, without the trouble of having to look up an object, update the object by incrementing an element, and insert the resulting object into the table again. The operation is guaranteed to be atomic and isolated.

This function destructively update the object with key Key in table Tab by adding Incr to the element at position Pos. The new counter value is returned. If no position is specified, the element directly following key (<keypos>+1) is updated.

If a Threshold is specified, the counter is reset to value SetValue if the following conditions occur:

A list of UpdateOp can be supplied to do many update operations within the object. The operations are carried out in the order specified in the list. If the same counter position occurs more than once in the list, the corresponding counter is thus updated many times, each time based on the previous result. The return value is a list of the new counter values from each update operation in the same order as in the operation list. If an empty list is specified, nothing is updated and an empty list is returned. If the function fails, no updates are done.

The specified Key is used to identify the object by either matching the key of an object in a set table, or compare equal to the key of an object in an ordered_set table (for details on the difference, see lookup/2 and new/2).

If a default object Default is specified, it is used as the object to be updated if the key is missing from the table. The value in place of the key is ignored and replaced by the proper key value. The return value is as if the default object had not been used, that is, a single updated element or a list of them.

The function fails with reason badarg in the following situations:

Types:

This function provides an efficient way to update one or more elements within an object, without the trouble of having to look up, update, and write back the entire object.

This function destructively updates the object with key Key in table Tab. The element at position Pos is given the value Value.

A list of {Pos,Value} can be supplied to update many elements within the same object. If the same position occurs more than once in the list, the last value in the list is written. If the list is empty or the function fails, no updates are done. The function is also atomic in the sense that other processes can never see any intermediate results.

Returns true if an object with key Key is found, otherwise false.

The specified Key is used to identify the object by either matching the key of an object in a set table, or compare equal to the key of an object in an ordered_set table (for details on the difference, see lookup/2 and new/2).

The function fails with reason badarg in the following situations:

Types:

This function returns the tid() of the named table identified by TableName, or undefined if no such table exists. The tid() can be used in place of the table name in all operations, which is slightly faster since the name does not have to be resolved on each call.

If the table is deleted, the tid() will be invalid even if another named table is created with the same name.