ets(3)
✨ ets(3) ✨
Erlang Module Definition — yes bestie, this is the manual page for ets, and we're gonna get through it together 💖
🌸 NAME 🌸
ets — Built-in term storage. That's it, that's the vibe.
💅 DESCRIPTION 💅
okay so. This module is the interface to the Erlang built-in term storage BIFs 🫶. What do they do? They let you store very large quantities of data inside an Erlang runtime system, and still have constant access time to that data. (Well — except for ordered_set, see below, where access time is proportional to the logarithm of the number of stored objects. Math is math.)
Your data lives in a bunch of dynamic tables, and tables store tuples. Every table is created by a process, and the moment that process terminates, the table just automatically gets destroyed 💀. Each table also has access rights, set at creation. No takebacks.
Tables come in four flavors: set, ordered_set, bag, and duplicate_bag 👑.
- A
setorordered_settable can only have one object associated with each key. - A
bagorduplicate_bagtable can have many objects associated with each key.
Insert and lookup times in tables of type set are constant, no matter how big the table is ✨. For bag and duplicate_bag, time is proportional to the number of objects with the same key. And lowkey, even seemingly unrelated keys may inflict linear search to be skipped past while looking for the key of interest — that's due to hash collision, iykyk.
WARNING: for tables of typebagandduplicate_bag, do not go inserting an extensive amount of objects with the same key. It will hurt insert and lookup performance and the real time characteristics of the runtime environment (hash bucket linear search do not yield). Bestie, I'm begging, spread your keys out 🙈.
The ordered_set table type uses a binary search tree 🌳. Insert and lookup times are proportional to the logarithm of the number of objects in the table.
NOTE: the number of tables stored at one Erlang node used to be limited. This is no longer the case (except by memory usage, obviously). The previous default limit was about1400tables and could be increased by setting the environment variableERL_MAX_ETS_TABLESor the command line option+ebefore starting the Erlang runtime system. That hard limit has been removed, but it is currently useful to setERL_MAX_ETS_TABLESanyway 🫡. It should be set to an approximate of the maximum amount of tables used, since an internal table for named tables is sized using this value. If large amounts of named tables are used andERL_MAX_ETS_TABLEShasn't been increased, the performance of named table lookup will degrade. So like… set it. For me.
Also notice: there is no automatic garbage collection for tables 😭. Even if there are no references to a table from any process, it is not automatically destroyed unless the owner process terminates. To destroy a table explicitly, use the function delete/1. The default owner is the process that created the table. To transfer table ownership at process termination, use option heir or call give_away/3. Wrap up your loose ends, babes.
Some implementation details 🧚:
- 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 functionsfirst/1andnext/2.
Notice the subtle difference between matching and comparing equal, which is demonstrated by table types set and ordered_set:
- Two Erlang terms match if they are of the same type and have the same value, so that
1matches1, but not1.0(as1.0is afloat/0and not aninteger/0). - 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
1compares equal to both1and1.0. - The
ordered_setworks on the Erlang term order and no defined order exists between aninteger/0and afloat/0that extends to the same value. Hence the key1and the key1.0are regarded as equal in anordered_settable. Iconic behavior honestly.
😵 Failures 😵
Functions in this module fail by raising an error exception with error reason:
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 (protectedorprivate).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.
🦋 Concurrency 🦋
This module provides some limited support for concurrent access 🤝. All updates to single objects are guaranteed to be both atomic and isolated. Which means an updating operation to a single object either succeeds or fails completely without any effect (that's atomicity 💅) and no intermediate results of the update can be seen by other processes (that's isolation ✨). Some functions that update many objects state that they even guarantee atomicity and isolation for the entire operation. In database terms the isolation level can be seen as "serializable", as if all isolated operations are carried out serially, one after the other in a strict order. No cutting in line, periodt.
🌈 Table traversal 🌈
There are different ways to traverse through the objects of a table. Pick your fighter:
- Single-step traversal one key at at time, using
first/1,next/2,last/1andprev/2. - Single-step traversal one key at at time, but using
first_lookup/1,next_lookup/2,last_lookup/1andprev_lookup/2. This is more efficient when you also need to lookup the objects for the keys. - Search with simple match patterns, using
match/1/2/3,match_delete/2andmatch_object/1/2/3. - Search with more powerful match specifications, using
select/1/2/3,select_count/2,select_delete/2,select_replace/2andselect_reverse/1/2/3. - Table conversions, using
tab2file/2/3andtab2list/1.
No table traversal will guarantee a consistent snapshot of the entire table if the table is also updated by concurrent processes during the traversal 😭. The result of each concurrently updated object may be seen (or not) depending on if it has happened when the traversal visits that part of the table. The only way to guarantee a full consistent table snapshot (if you really need that) is to disallow concurrent updates during the entire traversal. Sorry bestie, them's the rules.
Moreover, traversals not done in a safe way, on tables where keys are inserted or deleted during the traversal, may yield the following undesired effects 🙈:
- Any key may be missed.
- Any key may be found more than once.
- The traversal may fail with
badargexception if keys are deleted.
A table traversal is safe if either
- the table is of type
ordered_set. - the entire table traversal is done within one ETS function call.
- function
safe_fixtable/2is used to keep the table fixated during the entire traversal.
NOTE: even though the access of a single object is always guaranteed to be atomic and isolated, each traversal through a table to find the next key is not done with such guarantees. This is often not a problem, but may cause rare subtle "unexpected" effects if a concurrent process inserts objects during a traversal 👀. For example, consider one process doing
ets:new(t, [ordered_set, named_table]),
ets:insert(t, {1}),
ets:insert(t, {2}),
ets:insert(t, {3}),A concurrent call to ets:first(t), done by another process, may then in rare cases return 2 even though 2 has never existed in the table ordered as the first key. In the same way, a concurrent call to ets:next(t, 1) may return 3 even though 3 never existed in the table ordered directly after 1. Effects like this are improbable but possible. The probability will further be reduced (if not vanish) if table option write_concurrency is not enabled. This can also only be a potential concern for ordered_set where the traversal order is defined.
Traversals using match and select functions may not need to scan the entire table depending on how the key is specified 🔍. A match pattern with a fully bound key (without any match variables) will optimize the operation to a single key lookup without any table traversal at all. For ordered_set a partially bound key will limit the traversal to only scan a subset of the table based on term order. A partially bound key is either a list or a tuple with a prefix that is fully bound. Example:
1> T = ets:new(t,[ordered_set]), ets:insert(T, {"555-1234", "John Smith"}).
true
%% Efficient search of all with area code 555
2> ets:match(T,{[$5,$5,$5,$- |'$1'],'$2'}).
[["1234","John Smith"]]🎀 Match Specifications 🎀
Some of the functions use a match specification, match_spec. For a brief explanation, see select/2. For a detailed description, see section Match Specifications in Erlang in ERTS User's Guide.
A match specifications with excessive nesting will cause a system_limit error exception to be raised 💀.
⭐ DATA TYPES ⭐
comp_match_spec() :: compiled_match_spec().-opaque compiled_match_spec()
A compiled match specification.
continuation()
continuation() ::
'$end_of_table' |
{table(),
integer(),
integer(),
compiled_match_spec(),
list(),
integer()} |
{table(),
_, _,
integer(),
compiled_match_spec(),
list(),
integer(),
integer()}.Opaque continuation used by select/1,3, select_reverse/1,3, match/1,3, and match_object/1,3.
match_pattern()
match_pattern() :: atom() | tuple().match_spec()
match_spec() :: [{match_pattern(), [_], [_]}].A match specification, see Match Specifications.
tab()
tab() :: table().table()
table() :: atom() | tid().table_access()
table_access() :: public | protected | private.table_type()
table_type() :: set | ordered_set | bag | duplicate_bag.-opaque tid()
A table identifier, as returned by new/2.
👑 FUNCTIONS 👑
all() -> [Table] when Table :: table().
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. It's giving… a snapshot that isn't really a snapshot 😭.
delete(Table) -> true when Table :: table().
Deletes the entire table Table. Gone. Poof 💅.
delete(Table, Key) -> true when Table :: table(), Key :: term().
Bestie, delete/2 is the yeet button 💅 It deletes all the objects with key Key from table Table. And the iconic part? It succeeds even if no objects with key Key exist at all. No error, no drama, just true.
1> T = ets:new(t, []).
2> ets:insert(T, {k,1}).
true
3> ets:delete(T, k).
true
4> ets:lookup(T, k).
[]delete_all_objects(Table) -> true
when Table :: table().Deletes every object in the ETS table Table. And this one is lowkey a flex, because the operation is guaranteed to be atomic and isolated. Nobody's seeing a half-deleted table, no cap. ✨
Examples
1> T = ets:new(t, []).
2> ets:insert(T, [{a,1},{b,2}]).
true
3> ets:delete_all_objects(T).
true
4> ets:info(T, size).
0delete_object(Table, Object) -> true
when Table :: table(), Object :: tuple().Deletes the exact object Object from the ETS table, leaving objects with the same key but other differences (useful for type bag). And heads up: in a duplicate_bag table, all instances of the object are deleted. 🫶
Examples
1> T = ets:new(t, [bag]).
2> ets:insert(T, [{k,1},{k,2}]).
true
3> ets:delete_object(T, {k,1}).
true
4> ets:lookup(T, k).
[{k,2}]file2tab(Filename) -> {ok, Table} | {error, Reason}
when
Filename :: file:name(),
Table :: table(),
Reason :: term().Reads a file produced by tab2file/2 or tab2file/3 and creates the corresponding table Table. 🦋
Exactly equivalent to file2tab(Filename, []).
Examples
1> File = "ets_file2tab_example.ets".
"ets_file2tab_example.ets"
2> T = ets:new(t, []).
3> ets:insert(T, {k,1}).
true
4> ok = ets:tab2file(T, File).
ok
5> {ok, T2} = ets:file2tab(File), ets:lookup(T2, k).
[{k,1}]
6> ets:delete(T2), ok = file:delete(File).
okfile2tab(Filename, Options) -> {ok, Table} | {error, Reason}
when
Filename :: file:name(),
Table :: table(),
Options :: [Option],
Option :: {verify, boolean()},
Reason :: term().Same deal — reads a file produced by tab2file/2 or tab2file/3 and creates the corresponding table Table. 🌸
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 it does that 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. ⚠️ And 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]} with 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. It's giving expensive. 😭
{verify,false} is the default.
Examples
1> File = "ets_file2tab2_example.ets".
"ets_file2tab2_example.ets"
2> T = ets:new(t, []).
3> ets:insert(T, {k,1}).
true
4> ok = ets:tab2file(T, File, [{extended_info,[object_count]}]).
ok
5> {ok, _} = ets:file2tab(File, [{verify,true}]), ok = file:delete(File).
okfirst(Table) -> Key | '$end_of_table'
when Table :: table(), Key :: term().Returns the first key Key in table Table. 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. And if the table is empty, you get '$end_of_table' back — that's the little "no more, bestie" marker. 💀
To find subsequent keys in the table, use next/2.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{2,b},{1,a}]).
true
3> ets:first(T).
1first_lookup(Table) -> {Key, [Object]} | '$end_of_table'
when
Table :: table(),
Key :: term(),
Object :: tuple().Similar to first/1 except that it returns the object(s) along with the key stored in the table. This is equivalent to doing first/1 followed by a lookup/2. If the table is empty, '$end_of_table' is returned. ✨
To find subsequent objects in the table, use next_lookup/2.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{2,b},{1,a}]).
true
3> ets:first_lookup(T).
{1,[{1,a}]}foldl(Function, Acc0, Table) -> Acc1
when
Function :: fun((Element :: term(), AccIn) -> AccOut),
Table :: table(),
Acc0 :: term(),
Acc1 :: term(),
AccIn :: term(),
AccOut :: term().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.
Now the tea: 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. So don't be shook if the count comes out weird. 🙈
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,10},{2,20}]).
true
3> ets:foldl(fun({_,V}, A) -> A + V end, 0, T).
30foldr(Function, Acc0, Table) -> Acc1
when
Function :: fun((Element :: term(), AccIn) -> AccOut),
Table :: table(),
Acc0 :: term(),
Acc1 :: term(),
AccIn :: term(),
AccOut :: term().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 — so basically foldl's mirror image, she's the other half of the duo.
Same caveat as before: 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.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,10},{2,20}]).
true
3> ets:foldr(fun({_,V}, A) -> A + V end, 0, T).
30from_dets(Table, DetsTab) -> true
when Table :: table(), DetsTab :: dets:tab_name().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. So it's giving "merge, but make it lazy" 🍓
Careful bestie: if any of the tables does not exist, or the Dets table is not open, a badarg exception is raised. Not a vibe. 🚨
Examples
1> File = "ets_from_dets_example.dets".
"ets_from_dets_example.dets"
2> {ok,_} = dets:open_file(ets_from_dets_example, [{file, File}]).
{ok,ets_from_dets_example}
3> ok = dets:insert(ets_from_dets_example, {k,1}).
ok
4> T = ets:new(t, []).
5> ets:from_dets(T, ets_from_dets_example).
true
6> ets:lookup(T, k).
[{k,1}]
7> ok = dets:close(ets_from_dets_example), ok = file:delete(File).
okfun2ms(LiteralFun) -> MatchSpec
when LiteralFun :: function(), MatchSpec :: match_spec().OK so this is the ✨magic✨ one. It's a pseudo function that, by a parse_transform, translates LiteralFun typed as parameter in the function call to a match specification. And when we say "literal", we mean it: 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. No storing her in a variable and sneaking her in later, she has to arrive in person. 💅
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 — yes, that's the sneaky kind, so don't get caught out. 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. Periodt.
The return value is the resulting match specification.
Examples
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:
1> X=3.
3
2> 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: 🌈
1> X = 3, 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.
WARNING: If the parse_transform is not applied to a module that calls this pseudo function, the call fails in runtime (with abadarg). Theetsmodule exports a function with this name, but it is never to be called except when using the function in the shell. If the parse_transform is properly applied by including header filems_transform.hrl, compiled code never calls the function, but the function call is replaced by a literal match specification. 🛑
For more information, see ms_transform.
🎁 give_away — the gifting ritual
give_away(Table, Pid, GiftData) -> true
when
Table :: table(),
Pid :: pid(),
GiftData :: term().okay so this one literally hands over the keys to the castle 👑. It makes process Pid the brand-new owner of table Table. And when it works, the new owner gets a lil message: {'ETS-TRANSFER',Table,FromPid,GiftData}. adorable, honestly.
But the rules though, bestie, pay attention:
Pidhas to be alivePidhas to be localPidcan not already be the owner of the table- and the calling process has to be the table owner. no gifting other people's stuff 💀
Also heads-up: this function does not affect the heir option of the table. So like… an owner can set heir to itself, give the table away, and then bop it right back if the receiver terminates. loophole queen behavior, we love to see it ✨
Examples
1> Parent = self().
2> Giver = spawn(fun() ->
T = ets:new(t, []),
ets:give_away(T, Parent, gift)
end).
3> receive M -> M end.
{'ETS-TRANSFER', T, Giver, gift}👀 i() / i(Table) — the vibes inspection era
i() -> ok.Displays info about all the ETS tables, right there on your terminal. like a little table parade 🎀
i(Table) -> ok when Table :: table().Browses table Table on a terminal. one table, full spotlight, main character energy 💅
🔍 info/1 — the full dossier
info(Table) -> InfoList | undefined
when
Table :: table(),
InfoList :: [InfoTuple],
InfoTuple ::
{compressed, boolean()} |
{decentralized_counters, boolean()} |
{heir, pid() | none} |
{id, tid()} |
{keypos, pos_integer()} |
{memory, non_neg_integer()} |
{name, atom()} |
{named_table, boolean()} |
{node, node()} |
{owner, pid()} |
{protection, table_access()} |
{size, non_neg_integer()} |
{type, table_type()} |
{write_concurrency, boolean() | auto} |
{read_concurrency, boolean()}.Returns info about table Table as a list of tuples. the whole receipts file, no notes app screenshot needed 🧚
Edge cases, clock them:
- If
Tablehas the correct type for a table identifier, but does not refer to an existing ETS table →undefinedgets returned. - If
Tableis not of the correct type → abadargexception is raised. 💀
Now the tuple-by-tuple tea ☕:
{compressed, boolean()}— Indicates if the table is compressed.{decentralized_counters, boolean()}— Indicates whether the table usesdecentralized_counters.{heir, pid() | none}— The pid of the heir of the table, ornoneif no heir is set.{id, tid()}— The table identifier.{keypos, integer() >= 1}— The key position.{memory, integer() >= 0}— The number of words allocated to the table.{name, atom()}— The table name.{named_table, boolean()}— Indicates if the table is named.{node, node()}— The node where the table is stored. This field is no longer meaningful, as tables cannot be accessed from other nodes.{owner, pid()}— The pid of the owner of the table.{protection, access()}— The table access rights.{size, integer() >= 0}— The number of objects inserted in the table.{type, type()}— The table type.{read_concurrency, boolean()}— Indicates whether the table usesread_concurrencyor not.{write_concurrency, WriteConcurrencyAlternative}— Indicates whichwrite_concurrencyoption the table uses.
NOTE: The execution time of this function is affected by thedecentralized_counterstable option. The execution time is much longer when thedecentralized_countersoption is set totruethan when thedecentralized_countersoption is set tofalse. ⏳
Examples
1> T = ets:new(t, []).
2> lists:sort(ets:info(T)).
[{compressed,false},
{decentralized_counters,false},
{heir,none},
{id,_},
{keypos,1},
{memory,_},
{name,t},
{named_table,false},
{node,_},
{owner,_},
{protection,protected},
{read_concurrency,false},
{size,0},
{type,set},
{write_concurrency,false}]🔎 info/2 — one specific detail, pls
info(Table, Item) -> Value | undefined
when
Table :: table(),
Item ::
binary | compressed | decentralized_counters |
fixed | heir | id | keypos | memory | name |
named_table | node | owner | protection |
safe_fixed | safe_fixed_monotonic_time | size |
stats | type | write_concurrency |
read_concurrency,
Value :: term().Returns the info tied to Item for table Table, or returns undefined if Table doesn't refer to an existing ETS table. And if Table isn't the correct type, or if Item isn't one of the allowed values → badarg exception, raised 😭
On top of the {Item,Value} pairs already defined for info/1, these items are also allowed:
Item=binary,Value=BinInfo—BinInfois a list containing miscellaneous information about binaries kept by the table. ThisItemcan be changed or removed without prior notice. In the current implementationBinInfois a list of tuples{BinaryId,BinarySize,BinaryRefcCount}.Item=fixed,Value=boolean()— Indicates if the table is fixed by any process.Item=safe_fixed|safe_fixed_monotonic_time,Value={FixationTime,Info}|false— If the table is fixed usingsafe_fixtable/2, the call returns a tuple whereFixationTimeis the last time when the table changed from unfixed to fixed. The format and value ofFixationTimedepends onItem:safe_fixed—FixationTimecorresponds to the result returned byerlang:timestamp/0at the time of fixation. Notice that when the system uses single or multi time warp modes this can produce strange results, as the use ofsafe_fixedis not time warp safe. Time warp safe code must usesafe_fixed_monotonic_timeinstead.safe_fixed_monotonic_time—FixationTimecorresponds to the result returned byerlang:monotonic_time/0at the time of fixation. The use ofsafe_fixed_monotonic_timeis time warp safe. ✅Infois a possibly empty lists of tuples{Pid,RefCount}, one tuple for every process the table is fixed by now.RefCountis the value of the reference counter and it keeps track of how many times the table has been fixed by the process. Table fixations are not limited tosafe_fixtable/2. Temporary fixations may also be done by for example traversing functions likeselectandmatch. Such table fixations are automatically released before the corresponding functions returns, but they may be seen by a concurrent call toets:info(T,safe_fixed|safe_fixed_monotonic_time). If the table is not fixed at all, the call returnsfalse.
Item=stats,Value=tuple()— Returns internal statistics about tables on an internal format used by OTP test suites. Not for production use. 🙈
NOTE: The execution time of this function is affected by thedecentralized_counterstable option when the second argument of the function issizeormemory. The execution time is much longer when thedecentralized_countersoption is set totruethan when thedecentralized_countersoption is set tofalse. ⏳
Examples
1> T = ets:new(t, []), set = ets:info(T, type).
set🧺 init_table — the bulk-fill era
init_table(Table, InitFun) -> true
when
Table :: table(),
InitFun :: fun((Arg) -> Res),
Arg :: read | close,
Res ::
end_of_input |
{Objects :: [term()], InitFun} |
term().Replaces the existing objects of table Table 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. so like, don't come for it for performance reasons bestie, it's a nostalgia thing 😌
When called with argument read, the function InitFun is assumed to return end_of_input when there's 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. chaotic but that's the deal 🫠
Examples
1> T = ets:new(t, []).
2> Init = fun(read) -> {[{k,1}], fun(read) -> end_of_input; (close) -> ok end}; (close) -> ok end.
3> ets:init_table(T, Init).
true
4> ets:lookup(T, k).
[{k,1}]📥 insert — putting things in, the moment we've all been waiting for
insert(Table, ObjectOrObjects) -> true
when
Table :: table(),
ObjectOrObjects :: tuple() | [tuple()].Inserts the object, or all of the objects in list ObjectOrObjects, into table Table. drop them in, they're home now 🏡✨
And here's how each table type handles a collision:
- If the table type is
setand the key of the inserted objects matches the key of any object in the table, the old object is replaced. - If the table type is
ordered_setand the key of the inserted object compares equal to the key of any object in the table, the old object is replaced. - If the table type is
bagand the object matches any whole object in the table, the object is not inserted. - If the list has more than one object with matching keys and the table type is
set, one of them gets inserted — and which one is straight-up not defined. Same energy for table typeordered_setif the keys compare equal. It's giving chaos, bestie, and we don't make the rules 💅
The entire operation is guaranteed to be atomic and isolated, even when you're inserting a whole list of objects. Slay, no half-finished inserts.
For bag and duplicate_bag, objects in the list with identical keys get inserted in list order (from head to tail). Which means a later call to lookup(T,Key) hands them back to you in exactly that inserted order. Iconic and predictable. ✨
NOTE: forbagthe insertion order of identical keys described above got accidentally un-done in OTP 23.0 and was then fixed in OTP 25.3. So from OTP 23.0 up until OTP 25.3, objects in a list were inserted in reverse order (from tail to head). 😭 Forduplicate_bagthe same faulty reverse insertion exists from OTP 23.0 until OTP 25.3 — except it's unpredictable and may or may not happen, a longer list just makes the probability of reverse insertion go up. Fr fr, wild times.
Examples
1> T = ets:new(t, []).
2> ets:insert(T, {k,1}).
true
3> ets:lookup(T, k).
[{k,1}]insert_new(Table, ObjectOrObjects) -> boolean()
when
Table :: table(),
ObjectOrObjects :: tuple() | [tuple()].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 kicking around in the table (for bag and duplicate_bag), it returns false. Like, it just says no. 🙅
If ObjectOrObjects is a list, the function checks every key before inserting anything. Nothing gets inserted unless all keys present in the list are absent from the table. And just like insert/2, the whole operation is guaranteed to be atomic and isolated. Obsessed with the consistency.
Examples
1> T = ets:new(t, []).
2> true = ets:insert_new(T, {k,1}).
true
3> false = ets:insert_new(T, {k,2}).
falseis_compiled_ms(Term) -> boolean()
when Term :: term().Checks if a term represents a valid compiled match specification. And lowkey important: a compiled match specification is only valid on the Erlang node where it was compiled by calling match_spec_compile/1. Local girl, basically. 🌸
NOTE: before STDLIB 3.4 (OTP 20.0) compiled match specifications did not have an external representation. If you passed one throughbinary_to_term(term_to_binary(CMS))or sent it to another node and back, the result was always an empty binary<<>>. 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. So if you pass it throughbinary_to_term(term_to_binary(CMS))or send it to another node and back, the result may or may not be a valid compiled match specification — depends on whether the original compiled match specification was still alive. 💀
Examples
1> MS = ets:fun2ms(fun(X) -> X end).
2> ets:is_compiled_ms(MS).
false
3> CMS = ets:match_spec_compile(MS).
4> ets:is_compiled_ms(CMS).
truelast(Table) -> Key | '$end_of_table'
when Table :: table(), Key :: term().Returns the last key Key according to Erlang term order in table Table of type ordered_set. For any other table types, this function is basically synonymous to first/1 (no thoughts, head empty, same thing 🦋). If the table is empty, you get '$end_of_table' back.
Wanna find the keys before it? Use prev/2.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
true
3> ets:last(T).
2last_lookup(Table) -> {Key, [Object]} | '$end_of_table'
when
Table :: table(),
Key :: term(),
Object :: tuple().Similar to last/1 except it also hands you the object(s) alongside the key stored in the table. It's literally last/1 followed by a lookup/2, two-for-one deal 🎀. If the table is empty, '$end_of_table' is returned.
Wanna find the objects before it? Use prev_lookup/2.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
true
3> ets:last_lookup(T).
{2,[{2,b}]}lookup(Table, Key) -> [Object]
when Table :: table(), Key :: term(), Object :: tuple().Returns a list of all objects with key Key in table Table. Here's the vibe breakdown:
- For tables of type
set,bag, orduplicate_bag, an object is returned only if the specified key matches the key of the object in the table. - For tables of type
ordered_set, an object is returned if the specified key compares equal to the key of an object in the table.
The difference is the same as between =:= and ==. Iykyk. 👑
So like, as an example, you could insert an object with integer/0 1 as a key in an ordered_set and get that object back from a lookup/2 where you searched with float/0 1.0 as the key. Mathematical.
For tables of type set or ordered_set, the function returns either the empty list or a list with exactly one element, because there cannot be more than one object with the same key. For tables of type bag or duplicate_bag, you get a list of arbitrary length. Anything goes.
And notice — the sequential order of object insertions is preserved! The first object inserted with the specified key is the first in the resulting list, and so on. See also the note about list insertion order above. Consistency is the moment. ✨
Examples
1> T = ets:new(t, []).
2> ets:insert(T, {k,1}).
true
3> ets:lookup(T, k).
[{k,1}]lookup_element(Table, Key, Pos) -> Elem
when
Table :: table(),
Key :: term(),
Pos :: pos_integer(),
Elem :: term() | [term()].For a table Table of type set or ordered_set, this returns the Pos:th element of the object with key Key. Just that one lil element. 🍓
For tables of type bag or duplicate_bag, it returns a list with the Pos:th element of every object with key Key. So many elements, so little time.
If no object with key Key exists, the function exits with reason badarg. 😭
If Pos is larger than the size of any tuple with a matching key, the function exits with reason badarg. 💀
And the whole set/bag/duplicate_bag versus ordered_set situation — where ordered_set views keys as equal when they compare equal, while the other table types only count them equal when they match — holds for lookup_element/3 too. Not me reminding you twice, but yes.
Examples
1> T = ets:new(t, []).
2> ets:insert(T, {k,10,20}).
true
3> ets:lookup_element(T, k, 3).
20lookup_element(Table, Key, Pos, Default) -> Elem | Default
when
Table :: table(),
Key :: term(),
Pos :: pos_integer(),
Default :: term(),
Elem :: term() | [term()].For a table Table of type set or ordered_set, the function returns the Pos:th element of the object with key Key. Same deliciousness as before.
For tables of type bag or duplicate_bag, it returns a list with the Pos:th element of every object with key Key. 🦋
If no object with key Key exists, the function returns Default. No dramatic exit this time, she just hands you the default. 🫶
If Pos is larger than the size of any tuple with a matching key, the function exits with reason badarg. That part stays dramatic.
And yes bestie, the difference between set, bag, and duplicate_bag on one hand, and ordered_set on the other — ordered_set views keys as equal when they compare equal, the others only when they match — holds for lookup_element/4 as well. It's a whole family trait. 💜
Examples
1> T = ets:new(t, []).
2> ets:lookup_element(T, missing, 2, none).
nonematch(Continuation) -> {[Match], Continuation} | '$end_of_table'
when Match :: [term()], Continuation :: continuation().Continues a match that was started with match/3. The next chunk — sized exactly how you specified in the initial match/3 call — comes back along with a new Continuation, which you can then feed into subsequent calls to this function. It's giving "to be continued…" energy. 🌈
When there are no more objects in the table, '$end_of_table' is returned.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b},{3,c}]).
true
3> {[[{1,a}],[{2,b}]], C} = ets:match(T, '$1', 2).
4> ets:match(C).
{[[{3,c}]], '$end_of_table'}match(Table, Pattern) -> [Match]
when
Table :: table(),
Pattern :: match_pattern(),
Match :: [term()].Matches the objects in table Table against the pattern Pattern. A pattern is a term that can contain:
- Bound parts (Erlang terms)
'_'which matches any Erlang term- Pattern variables
'$N', whereN=0,1,...
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:
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{rufsen,dog,7}, {brunte,horse,5}, {ludde,dog,5}]).
3> ets:match(T, '$1').
[[{brunte,horse,5}],[{ludde,dog,5}],[{rufsen,dog,7}]]
4> ets:match(T, {'_',dog,'$1'}).
[[5],[7]]
5> ets:match(T, {'_',cow,'$1'}).
[]If the key is specified in the pattern, the match is very efficient — arena tour, front row seats, no line. If the key is not specified, that is, if it's a variable or an underscore, the entire table must be searched. And the search time can be substantial if the table is very large. 🐌 Be mindful, bestie.
For tables of type ordered_set, the result comes in the same order as in a first/next traversal.
match(Table, Pattern, Limit) 💖
match(Table, Pattern, Limit) ->
{[Match], Continuation} | '$end_of_table'
when
Table :: table(),
Pattern :: match_pattern(),
Limit :: pos_integer(),
Match :: [term()],
Continuation :: continuation().okay bestie so this is exactly like match/2, but it's giving ✨portion control✨ — you get back only a limited (Limit) number of matching objects instead of the whole thing. The Continuation term can then be passed into subsequent calls to match/1 to scoop up the next chunk of matching objects. 🍓
The way that this is a space-efficient way to work on objects in a table… obsessed. It's faster than traversing the table object by object using first/1 and next/2. no cap fr fr. 🔥
If the table is empty, '$end_of_table' gets returned. that's it, that's the vibe.
Usesafe_fixtable/2to guarantee safe traversal for subsequent calls tomatch/1. 🫶
Examples 🎀
1> T = ets:new(t, []).
2> ets:insert(T, [{a,1},{b,2}]).
true
3> ets:match(T, '$1', 1).
{[[{a,1}]],_}match_delete(Table, Pattern) 🦋
match_delete(Table, Pattern) -> true
when Table :: table(), Pattern :: match_pattern().Deletes all objects that match pattern Pattern from table Table. Saying bye bye bye 👑. For a description of patterns, see match/2.
Examples 🌸
1> T = ets:new(t, []).
2> ets:insert(T, [{a,1},{b,2},{c,2}]).
true
3> ets:match_delete(T, {'_',2}).
true
4> ets:info(T, size).
1match_object(Continuation) 💅
match_object(Continuation) ->
{[Object], Continuation} | '$end_of_table'
when
Object :: tuple(),
Continuation :: continuation().Continues a match that was started with match_object/3. The next chunk of the size you specified in the initial match_object/3 call comes back, plus a fresh Continuation that you can then feed into subsequent calls to this function. it's giving multi-part saga energy 📖.
When there are no more objects left in the table, '$end_of_table' is returned.
Examples ⭐
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,a},{3,a},{4,b}]).
true
3> {_, C} = ets:match_object(T, {'_', a}, 2).
{[{1,a},{2,a}], _}
4> ets:match_object(C).
{[{3,a}], '$end_of_table'}match_object(Table, Pattern) 🌈
match_object(Table, Pattern) -> [Object]
when
Table :: table(),
Pattern :: match_pattern(),
Object :: tuple().Matches the objects in table Table against pattern Pattern. For a description of patterns, see match/2. The function returns a list of all objects that match the pattern. it literally gives you everything 💖.
If the key is specified in the pattern, the match is very efficient ⚡. But if the key is not specified — that is, if it's a variable or an underscore — then the entire table must be searched. Heads up bestie: 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. periodt. 💅
Examples 🎀
1> T = ets:new(t, []).
2> ets:insert(T, [{a,1},{b,2}]).
true
3> ets:match_object(T, {b,'_'}).
[{b,2}]match_object(Table, Pattern, Limit) 🧚
match_object(Table, Pattern, Limit) ->
{[Object], Continuation} | '$end_of_table'
when
Table :: table(),
Pattern :: match_pattern(),
Limit :: pos_integer(),
Object :: tuple(),
Continuation :: continuation().Works like match_object/2, but only returns a limited (Limit) number of matching objects. The Continuation term can then be used in subsequent calls to match_object/1 to grab the next chunk of matching objects. Space-efficient way to work on objects in a table — and faster than traversing the table object by object using first/1 and next/2. ate. 🔥
If the table is empty, '$end_of_table' is returned.
Usesafe_fixtable/2to guarantee safe traversal for subsequent calls tomatch_object/1. 🫶
Examples ✨
1> T = ets:new(t, []).
2> ets:insert(T, [{a,1},{b,2}]).
true
3> ets:match_object(T, {b,'_'}, 1).
{[{b,2}],_}match_spec_compile(MatchSpec) 💜
match_spec_compile(MatchSpec) -> CompiledMatchSpec
when
MatchSpec :: match_spec(),
CompiledMatchSpec ::
compiled_match_spec().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 — do not peek at it, it's not for you 🙈. 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. so. valid input only, bestie 💀.
NOTE: This function has limited use in normal code. It is used by thedetsmodule to perform thedets:select/1operations. iykyk 🎀
Examples 🌸
1> MS = ets:fun2ms(fun(X) -> X end).
2> CMS = ets:match_spec_compile(MS).
3> [foo] = ets:match_spec_run([foo], CMS).
[foo]match_spec_run(List, CompiledMatchSpec) 🦋
match_spec_run(List, CompiledMatchSpec) -> list()
when
List :: [term()],
CompiledMatchSpec :: compiled_match_spec().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 — it's hence the internal representation of the match specification you want 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. do with that what you will 💅.
Examples ⭐
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),NOTE: This function has limited use in normal code. It is used by thedetsmodule to perform thedets:select/1operations and byMnesiaduring transactions. 🎀
member(Table, Key) 💖
member(Table, Key) -> boolean()
when Table :: table(), Key :: term().Works like lookup/2, but does not return the objects — just the tea ☕. Returns true if one or more elements in the table has key Key, otherwise false. simple as. 🫶
Examples 🌈
1> T = ets:new(t, []).
2> ets:insert(T, {k,1}).
3> ets:member(T, k).
truenew(Name, Options) 👑
new(Name, Options) -> table()
when
Name :: atom(),
Options :: [Option],
Option ::
Type | Access | named_table |
{keypos, Pos} |
{heir, Pid} |
{heir, Pid, HeirData} |
{heir, none} |
Tweaks,
Type :: table_type(),
Access :: table_access(),
WriteConcurrencyAlternative :: boolean() | auto,
Tweaks ::
{write_concurrency, WriteConcurrencyAlternative} |
{read_concurrency, boolean()} |
{decentralized_counters, boolean()} |
compressed,
Pos :: pos_integer(),
Pid :: pid(),
HeirData :: term().Creates a new table and returns a table identifier that can be used in subsequent operations. The table identifier can even be sent to other processes so that a table can be shared between different processes within a node. it's giving social butterfly energy 🦋✨.
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}]. no cap 📝.
set— The table is asettable: one key, one object, no order among objects. This is the default table type. 💅ordered_set— The table is anordered_settable: one key, one object, ordered in Erlang term order, which is the order implied by the<and>operators. Tables of this type have a somewhat different behavior in some situations than tables of other types. Most notably,ordered_settables regard keys as equal when they compare equal, not only when they match. This means that to anordered_settable, integer1and float1.0are regarded as equal. 😳 This also means that the key used to lookup an element does not necessarily match the key in the returned elements, if floats and integers are mixed in keys of a table. wild fr fr.bag— The table is abagtable, which can have many objects, but only one instance of each object, per key. 🎀duplicate_bag— The table is aduplicate_bagtable, which can have many objects, including multiple copies of the same object, per key. ✨public— Any process can read or write to the table. 🌈protected— The owner process can read and write to the table. Other processes can only read the table. This is the default setting for the access rights. 🔒private— Only the owner process can read or write to the table. 🙈named_table— If this option is present, the table is registered under itsNamewhich can then be used instead of the table identifier in subsequent operations. 👑
The function will also return the Name instead of the table identifier. To get the table identifier of a named table, use whereis/1. 💜
{keypos,Pos}— tells ETS which element of the stored tuples is the key. Default is the first element, soPos=1. But bestie, that's not always it 💅 — especially if you wanna shove Erlang records in a table, you do not want element one to be the key.
Also, heads up: every single tuple you store in the table has to have at least Pos elements. No shortcuts.
{heir,Pid,HeirData}|{heir,Pid}|{heir,none}— makes a process the heir 👑, and that heir inherits the table if the owner terminates. If you passHeirData, a message{'ETS-TRANSFER',tid(),FromPid,HeirData}gets sent to the heir when that happens. If you just give{heir,Pid}, no'ETS-TRANSFER'message goes out — so you have to make sure the heir finds out some other way (a link or a monitor, for example), otherwise the table just sits there being unnoticed by its new owner 😭.
The heir must be a local process. Default heir is none, which destroys the table when the owner terminates. 💀
{write_concurrency,WriteConcurrencyAlternative}— performance tuning ✨. Defaults tofalse, and when it'sfalse, an operation that mutates (writes to) the table grabs exclusive access, blocking any concurrent access to the same table until it's finished. Set it totrueand the table is optimized for concurrent write access: different objects of the same table can be mutated (and read) by concurrent processes. That's achieved to some degree — at the expense of memory consumption and the performance of sequential access and concurrent reading.
The auto alternative for the write_concurrency option is like the true option but it automatically adjusts the synchronization granularity during runtime depending on how the table is used. This is the recommended write_concurrency option when you're on Erlang/OTP 25 and above, because it performs well in most scenarios. 👑
You can combine write_concurrency with the read_concurrency and decentralized_counters options. You typically want to combine write_concurrency with read_concurrency when large concurrent read bursts and large concurrent write bursts are common — for more info, peep the read_concurrency option. And it is almost always a good idea to combine write_concurrency with decentralized_counters.
Notice that this option does not change any guarantees about atomicity and isolation 🫶. Functions that make such promises over many objects (like insert/2) gain less (or nothing) from this option.
The memory consumption inflicted by both write_concurrency and read_concurrency is a constant overhead per table for set, bag and duplicate_bag when the true alternative for the write_concurrency option is not used. For all tables with the auto alternative, and for ordered_set tables with the true alternative, the memory overhead depends on the amount of actual detected concurrency during runtime. That overhead can get especially large when both write_concurrency and read_concurrency are combined.
NOTE: Prior tostdlib-3.7(OTP-22.0)write_concurrencyhad no effect onordered_set.
NOTE: Theautoalternative for thewrite_concurrencyoption is only available inOTP-25.0and above.
{read_concurrency,boolean()}— (Since OTP R14B) — performance tuning ✨. Defaults tofalse. Set it totrueand the table is optimized for concurrent read operations: read operations become much cheaper, especially on systems with multiple physical processors. The catch? Switching between read and write operations becomes more expensive.
You typically want to enable this when concurrent read operations are way more frequent than write operations, or when concurrent reads and writes come in large read and write bursts — that is, many reads not interrupted by writes, and many writes not interrupted by reads.
You typically do not want to enable this when the common access pattern is a few read operations interleaved with a few write operations, over and over. In that case enabling this option gives you a performance degradation 🙈.
read_concurrency can be combined with write_concurrency. You typically want to combine them when large concurrent read bursts and large concurrent write bursts are common.
{decentralized_counters,boolean()}— (Since OTP 23.0) — performance tuning ✨. Defaults totruefor all tables with thewrite_concurrencyoption set toauto. For tables of typeordered_setthe option also defaults totruewhen thewrite_concurrencyoption is set totrue. The option defaults tofalsefor all other configurations. This option has no effect if thewrite_concurrencyoption is set tofalse.
When this option is true, the table is optimized for frequent concurrent calls to operations that modify the table's size and/or its memory consumption (e.g. insert/2 and delete/2). The drawback 🥲 is that calls to info/1 and info/2 with size or memory as the second argument can get much slower when the decentralized_counters option is turned on.
When this option is enabled, the counters for the table size and memory consumption are distributed over several cache lines, and the scheduling threads are mapped to one of those cache lines. The erl option +dcg can be used to control the number of cache lines that the counters are distributed over.
compressed— (Since OTP R14B01) — if this option is present, the table data is stored in a more compact format to consume less memory 🍓. However, it will make table operations slower. Especially operations that need to inspect entire objects, likematchandselect, get much slower. The key element is not compressed.
Examples
1> ets:new(my_table, [named_table]).
my_table
2> ets:whereis(my_table) =/= undefined.
truenext/2
next(Table, Key1) -> Key2 | '$end_of_table'
when Table :: table(), Key1 :: term(), Key2 :: term().Returns the next key Key2, following key Key1 in table Table. 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 of whether Key1 ever existed in the table.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
3> ets:next(T, 1).
2next_lookup/2
next_lookup(Table, Key1) -> {Key2, [Object]} | '$end_of_table'
when
Table :: table(),
Key1 :: term(),
Key2 :: term(),
Object :: tuple().Similar to next/2 except that it hands you the object(s) along with the key stored in the table 💖. It's equivalent to doing next/2 followed by a lookup/2. If no next key exists, '$end_of_table' is returned.
It can be interleaved with next/2 during traversal.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
3> ets:next_lookup(T, 1).
{2,[{2,b}]}prev/2
prev(Table, Key1) -> Key2 | '$end_of_table'
when Table :: table(), Key1 :: term(), Key2 :: term().Returns the previous key Key2, preceding key Key1 according to Erlang term order in table Table 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.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
3> 1 = ets:prev(T, 2).
1prev_lookup/2
prev_lookup(Table, Key1) -> {Key2, [Object]} | '$end_of_table'
when
Table :: table(),
Key1 :: term(),
Key2 :: term(),
Object :: tuple().Similar to prev/2 except that it returns the object(s) along with the key stored in the table 💖. This is equivalent to doing prev/2 followed by a lookup/2. If no previous key exists, '$end_of_table' is returned.
It can be interleaved with prev/2 during traversal.
Examples
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
3> {1,[{1,a}]} = ets:prev_lookup(T, 2).
{1,[{1,a}]}rename/2
rename(Table, Name) -> Name when Table :: table(), Name :: atom().Renames the named table Table to the new name Name. Afterwards, the old name cannot be used to access the table. Renaming an unnamed table has no effect.
Examples
1> ets_rename_old = ets:new(ets_rename_old, [named_table]).
ets_rename_old
2> ets_rename_new = ets:rename(ets_rename_old, ets_rename_new).
ets_rename_new
3> undefined = ets:whereis(ets_rename_old), ets_rename_new = ets:info(ets_rename_new, name).
ets_rename_new
4> ets:delete(ets_rename_new).
truerepair_continuation/2
repair_continuation(Continuation, MatchSpec) -> Continuation
when
Continuation :: continuation(),
MatchSpec :: match_spec().Restores an opaque continuation returned by select/3 or select/1 if the continuation has passed through external term format — like when it's been sent between nodes or stored on disk 📀.
The reason this function exists at all? Continuation terms have compiled match specifications baked into them 💀, so they can get invalidated if you convert them to external term format. But since 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 after it's been stored on disk or on another node. Slay. ✨
Examples 💖
So this sequence of calls? It 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).But this sequence works, because 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)).NOTE: This function is rarely needed in application code. It is used by Mnesia to provide distributedselect/3andselect/1sequences. A normal application would either use Mnesia or keep the continuation from being converted to external format. 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. Seeis_compiled_ms/1.
🦋 safe_fixtable/2 🦋
safe_fixtable(Table, Fix) -> true
when Table :: table(), Fix :: boolean().Fixes a table of type set, bag, or duplicate_bag so you can traverse it safely with 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(Table, true). The table stays fixed until the process releases it by calling safe_fixtable(Table, false), or until the process terminates.
If a bunch of processes fix a table, it stays fixed until all of them have released it (or terminated). There's a reference counter kept on a per-process basis, and N consecutive fixes requires N releases to actually release the table. periodt. 👑
When a table is fixed, a sequence of first/1 and next/2 calls is 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 whether the key exists at the time next/2 is called. 🤷♀️
Examples ✨
clean_all_with_value(Table,X) ->
safe_fixtable(Table,true),
clean_all_with_value(Table,X,ets:first(Table)),
safe_fixtable(Table,false).
clean_all_with_value(Table,X,'$end_of_table') ->
true;
clean_all_with_value(Table,X,Key) ->
case ets:lookup(Table,Key) of
[{Key,X}] ->
ets:delete(Table,Key);
_ ->
true
end,
clean_all_with_value(Table,X,ets:next(Table,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. 😭 And the performance of operations on the table also degrades significantly. Not the vibe, bestie.
To find out which processes have fixed which tables, use info(Table, 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, fr fr.
Also notice thatsafe_fixtable/2is not necessary for table typeordered_setand for traversals done by a single ETS function call, likeselect/2. 💅
🌸 select/1 🌸
select(Continuation) -> {[Match], Continuation} | '$end_of_table'
when Match :: term(), Continuation :: continuation().Continues a match that was 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 then be used in subsequent calls to this function. 🔥
When there are no more objects in the table, '$end_of_table' is returned.
Examples ✨
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
true
3> MS = ets:fun2ms(fun(X) -> X end).
[{'$1',[],['$1']}]
4> {_, C} = ets:select(T, MS, 1).
5> {L,_} = ets:select(C), is_list(L).
true💜 select/2 💜
select(Table, MatchSpec) -> [Match]
when
Table :: table(),
MatchSpec :: match_spec(),
Match :: term().Matches the objects in table Table using a match specification. This is a more general call than the match/2 and match_object/2 calls. In its simplest form, the match specification goes like this:
MatchSpec = [MatchFunction]
MatchFunction = {MatchHead, [Guard], [Result]}
MatchHead = "Pattern as in ets:match"
Guard = {"Guardtest name", ...}
Result = "Term construct"So the match specification is always a list of one or more tuples (of arity 3). The first element of the tuple is a pattern as described in match/2. The second element of the tuple is a list of 0 or more guard tests (described below). The third element of the tuple is a list containing a description of the value to return. In almost all normal cases, that 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(Table,{'$1','$2','$3'})is exactly equivalent to:
ets:select(Table,[{{'$1','$2','$3'},[],['$$']}])And that the following match_object/2 call:
ets:match_object(Table,{'$1','$2','$1'})is exactly equivalent to:
ets:select(Table,[{{'$1','$2','$1'},[],['$_']}])Composite terms can be constructed in the Result part either by simply writing a list, so that this code:
ets:select(Table,[{{'$1','$2','$3'},[],['$$']}])gives the same output as:
ets:select(Table,[{{'$1','$2','$3'},[],[['$1','$2','$3']]}])That is, all the bound variables in the match head as a list. If you want to construct tuples, you have to write a tuple of arity 1 where the single element in that tuple is the tuple you want to construct (because an ordinary tuple can be mistaken for a Guard 😭).
Therefore the following call:
ets:select(Table,[{{'$1','$2','$1'},[],['$_']}])gives the same output as:
ets:select(Table,[{{'$1','$2','$1'},[],[{{'$1','$2','$3'}}]}])This syntax is equivalent to the syntax used in the trace patterns (see the dbg 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', you'd write the test as {is_list, '$1'}. If the test fails, the object in the table doesn't 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 < 4711is 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 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. 🌈
🎀 select/3 🎀
select(Table, MatchSpec, Limit) ->
{[Match], Continuation} | '$end_of_table'
when
Table :: table(),
MatchSpec :: match_spec(),
Limit :: pos_integer(),
Match :: term(),
Continuation :: continuation().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, and it's 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. 🔥
Examples ✨
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b}]).
true
3> MS = ets:fun2ms(fun({K,_}=Obj) when K =:= 2 -> Obj end).
4> ets:select(T, MS, 1).
{[{2,b}],_}⭐ select_count/2 ⭐
select_count(Table, MatchSpec) -> NumMatched
when
Table :: table(),
MatchSpec :: match_spec(),
NumMatched :: non_neg_integer().Matches the objects in table Table using a match specification. If and only if the match specification returns true for an object, that object is 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. no cap. 🙈
The function returns the number of objects matched. 💖
Examples 🌸
1> T = ets:new(t, []).
2> ets:insert(T, [{a,1},{b,2},{c,2}]).
true
3> MS = ets:fun2ms(fun({_,V}) when V =:= 2 -> true end).
4> ets:select_count(T, MS).
2Periodt. She counted exactly the two objects that matched and gave you a plain number back. 💅
select_delete(Table, MatchSpec) — the match-and-yeet 💀
select_delete(Table, MatchSpec) -> NumDeleted
when
Table :: table(),
MatchSpec :: match_spec(),
NumDeleted :: non_neg_integer().So basically this one matches objects in table Table using a match specification, and then — and this is the whole vibe — if and only if the match spec returns true for an object, that object gets removed from the table. Any other result from the match spec and the object stays exactly where it is, untouched, living its life. ✨
Basically it's the glow-up version of match_delete/2 — way more general, more power, more options.
It hands you back the number of objects it deleted from the table. 🔢
NOTE, bestie, this is important: the match specification has to return the atom true if you want the object deleted. No other return value gets the object deleted. None. Zero. So you literally cannot use the same match spec for looking up elements as for deleting them — it's giving different jobs, different specs. 🚫
Examples 🎀
1> T = ets:new(t, []).
2> ets:insert(T, [{a,1},{b,2},{c,2}]).
true
3> MS = ets:fun2ms(fun({_,V}) when V =:= 2 -> true end).
4> 2 = ets:select_delete(T, MS), ets:info(T, size).
1See how it deleted 2 objects and the table size dropped to 1? Ate and left no crumbs. 🍓
select_replace(Table, MatchSpec) — the glow-up function 👑
select_replace(Table, MatchSpec) -> NumReplaced
when
Table :: table(),
MatchSpec :: match_spec(),
NumReplaced :: non_neg_integer().Okay so this one matches the objects in table Table using a match specification, and for every single matched object, the existing object gets replaced with the match specification result. It's not deleting, it's not adding — it's a full makeover. 💅
Now the technical tea, because this matters:
- The match-and-replace operation for each individual object is guaranteed to be atomic and isolated. 🔒
- The
select_replacetable traversal as a whole, like all other select functions, does not give such guarantees. So per-object: safe. Whole traversal: not promised. - The match specification must be guaranteed to retain the key of any matched object. If it doesn't,
select_replacewill fail withbadargwithout updating any objects. So it's all-or-nothing, no partial mess left behind. - For the moment, due to performance and semantic constraints, tables of type
bagare not yet supported. 🙈
It 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]}]And here's a generic single object compare-and-swap operation, if that's the energy you're on today:
[Old] = ets:lookup(T, Key),
New = update_object(Old),
Success = (1 =:= ets:select_replace(T, [{Old, [], [{const, New}]}])),Main character CAS behaviour, no cap. 🔥
select_reverse(Continuation) — going backwards, but make it fashion 🦋
select_reverse(Continuation) ->
{[Match], Continuation} | '$end_of_table'
when
Continuation :: continuation(),
Match :: term().Continues a match that was 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 (so it walks backwards, bestie 🚶♀️). The returned list also contains objects with keys in reverse order. For all other table types, the behaviour is exactly that of select/1.
Examples 🌈
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).10, 9, 8, 7… 6, 5, 4, 3… 2, 1. Down to the very last crumb. 🍓
select_reverse(Table, MatchSpec) — same as select/2 but in reverse 💫
select_reverse(Table, MatchSpec) -> [Match]
when
Table :: table(),
MatchSpec :: match_spec(),
Match :: term().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. So if your table isn't an ordered_set, don't expect a plot twist. 🙈
Examples ✨
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b},{3,c}]).
true
3> MS = ets:fun2ms(fun({K,_}) -> K end).
4> ets:select_reverse(T, MS).
[3,2,1]3,2,1 — countdown energy. 😭
select_reverse(Table, MatchSpec, Limit) — last ones first 💜
select_reverse(Table, MatchSpec, Limit) ->
{[Match], Continuation} | '$end_of_table'
when
Table :: table(),
MatchSpec :: match_spec(),
Limit :: pos_integer(),
Match :: term(),
Continuation :: continuation().Works like select/3, but for table type ordered_set the 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, bestie. Because the result list is not only reversed — it also contains the last Limit matching objects in the table, not the first. Different objects, different vibe. 🫶
Examples 🎀
1> T = ets:new(t, [ordered_set]).
2> ets:insert(T, [{1,a},{2,b},{3,c}]).
true
3> MS = ets:fun2ms(fun({K,_}) -> K end).
4> {L, C} = ets:select_reverse(T, MS, 2), (L =:= [3,2]) andalso is_tuple(C).
truesetopts(Table, Opts) — change one setting, that's it 💅
setopts(Table, Opts) -> true
when
Table :: table(),
Opts :: Opt | [Opt],
Opt ::
{heir, Pid} |
{heir, Pid, HeirData} |
{heir, none},
Pid :: pid(),
HeirData :: term().Sets table options. The only allowed option to be set after the table has been created is heir. And heads up: the calling process must be the table owner. 👑
Examples ✨
1> T = ets:new(t, []), true = ets:setopts(T, {heir, none}).
trueslot(Table, I) — the debugging bestie 🧚
slot(Table, I) -> [Object] | '$end_of_table'
when
Table :: table(),
I :: non_neg_integer(),
Object :: tuple().This function is mostly for debugging purposes — normally you'd reach for first/next or last/prev instead. Lowkey the retro option, iykyk. 🎀
Returns all objects in slot I of table Table. You can traverse a table by repeatedly calling this function, starting with the first slot I=0 and ending when '$end_of_table' comes back. If argument I is out of range, the function fails with reason badarg. 💀
Unless a table of typeset,bag, orduplicate_bagis protected usingsafe_fixtable/2, a traversal can fail if concurrent updates are made to the table. So if other processes are out there editing at the same time, no guarantees, bestie. 😭
For table type ordered_set, the function returns a list containing object I in Erlang term order.
Examples 🌸
1> T = ets:new(t, []), true = ets:insert(T, {a,1}), true = is_list(ets:slot(T, 0)).
truetab2file(Table, Filename) — dump it to a file, easy mode 💾
tab2file(Table, Filename) -> ok | {error, Reason}
when
Table :: table(),
Filename :: file:name(),
Reason :: term().Dumps table Table to file Filename.
Equivalent to tab2file(Table, Filename,[]) — that's literally the whole thing, no extra seasoning. 🧂
Examples ✨
1> File = "ets_tab2file_example.ets".
"ets_tab2file_example.ets"
2> T = ets:new(t, []).
3> ets:insert(T, {k,1}).
true
4> ok = ets:tab2file(T, File).
ok
5> {ok, T2} = ets:file2tab(File), ets:lookup(T2, k).
[{k,1}]
6> ets:delete(T2), ok = file:delete(File).
okSave it, load it, look it up, delete it. The full circle moment. 🔄
tab2file(Table, Filename, Options) — dump it, but with receipts 🔍
tab2file(Table, Filename, Options) -> ok | {error, Reason}
when
Table :: table(),
Filename :: file:name(),
Options :: [Option],
Option ::
{extended_info, [ExtInfo]} | {sync,
boolean()},
ExtInfo :: md5sum | object_count,
Reason :: term().Dumps table Table 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. So don't skip it if you care about trust. 🙈
Option extended_info specifies what extra information is written to the table dump:
object_count— the number of objects written to the file is noted in the file footer, so file truncation can be verified even if the file was updated during dump. 🔢md5sum— the header and objects in the file are checksummed using the built-in MD5 functions. The MD5 sum of all objects is written in the file footer, so that verification while reading detects the slightest bitflip in the file data. Using this costs a fair amount of CPU time. 💅
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}. So by default it's the chill version, and you have to opt into the "actually committed to disk" behaviour. 🌈
✨ Examples ✨
1> File = "ets_tab2file3_example.ets".
"ets_tab2file3_example.ets"
2> T = ets:new(t, []).
3> ets:insert(T, {k,1}).
true
4> ok = ets:tab2file(T, File, [{extended_info,[object_count]}]).
ok
5> {ok, _} = ets:file2tab(File, [{verify,true}]), ok = file:delete(File).
okSee how the {verify,true} on the way back in is doing a little vibe check against the {extended_info,[object_count]} we wrote into the footer? Iconic. Then we yeet the file with file:delete/1. 🧼
🫶 tab2list(Table) -> [Object]
tab2list(Table) -> [Object]
when Table :: table(), Object :: tuple().Hands you back a list containing literally every object currently sitting in table Table. That's the whole gig, no notes. 💅
🎀 tabfile_info(Filename) -> {ok, TableInfo} | {error, Reason}
tabfile_info(Filename) -> {ok, TableInfo} | {error, Reason}
when
Filename :: file:name(),
TableInfo :: [InfoItem],
InfoItem ::
{name, atom()} |
{type, Type} |
{protection, Protection} |
{named_table, boolean()} |
{keypos, non_neg_integer()} |
{size, non_neg_integer()} |
{extended_info, [ExtInfo]} |
{version,
{Major :: non_neg_integer(),
Minor :: non_neg_integer()}},
ExtInfo :: md5sum | object_count,
Type ::
bag | duplicate_bag | ordered_set | set,
Protection :: private | protected | public,
Reason :: term().This is the one that spills the tea about a table that got dumped to a file by tab2file/2 or tab2file/3. She's nosy in the best way. Here's everything she reports back, item by item:
name— the name of the dumped table. Heads up: if it was a named table, then a table with that same name cannot exist at the moment you load it back from the file withfile2tab/2. And if the table was not saved as a named table, this field is basically meaningless when you load it from the file. Soz. 🙈type— the ETS type of the dumped table (akaset,bag,duplicate_bag, orordered_set). This is the type that gets used when you load her back up.protection— the protection of the dumped table (akaprivate,protected, orpublic). A table loaded from the file inherits the exact same protection. Same energy, always. ✨named_table—trueif the table was a named table when it was dumped to file, otherwisefalse. And notice: when a named table gets loaded from a file, there cannot already exist a table in the system with that same name. No duplicates bestie.keypos— the keypos of the table dumped to file, which is what gets used when loading the table again.size— the number of objects in the table at the moment the table dump to file started. Careful with this one: for apublictable, this number does not need to correspond to the number of objects actually saved to the file, because another process can have added or deleted objects during the table dump. Race conditions said hi. 💀extended_info— the extended information written in the file footer, which is what allows stronger verification during table loading from file, exactly as specified totab2file/3. Real talk though: this function only tells you which information is present, not the actual values in the file footer. The value is a list containing one or more of the atomsobject_countandmd5sum.version— a tuple{Major,Minor}holding the major and minor version of the file format for ETS table dumps. This version field was added beginning with STDLIB 1.5.1. Files dumped with older versions return{0,0}in this field. Ancient behavior ngl. 🏺
And if the file is inaccessible, badly damaged, or wasn't produced with tab2file/2 or tab2file/3? You get an error. Periodt.
✨ Examples ✨
1> File = "ets_tabfile_info_example.ets".
"ets_tabfile_info_example.ets"
2> T = ets:new(t, []).
3> ets:insert(T, {k,1}).
true
4> ok = ets:tab2file(T, File).
ok
5> {ok, Info} = ets:tabfile_info(File), is_list(Info).
true
6> file:delete(File).
ok🌈 table(Table, Options) -> QueryHandle
table(Table, Options) -> QueryHandle
when
Table :: table(),
QueryHandle :: qlc:query_handle(),
Options :: [Option] | Option,
Option ::
{n_objects, NObjects} |
{traverse, TraverseMethod},
NObjects :: default | pos_integer(),
TraverseMethod ::
first_next | last_prev | select |
{select, MatchSpec :: match_spec()}.Returns a Query List Comprehension (QLC) query handle. So the qlc module has this whole query language that's mainly aimed at Mnesia, but plot twist — ETS tables, Dets tables, and even plain lists are recognized by QLC as sources of data too. Calling table/1,2 is literally the way to make your ETS table Table usable to QLC. Main character move. 👑
When there are only simple restrictions on the key position, QLC goes and uses lookup/2 to look up the keys. But when that's not possible, the whole table gets traversed. And the traverse option decides how that goes down:
first_next— the table is traversed one key at a time by callingfirst/1andnext/2.last_prev— the table is traversed one key at a time by callinglast/1andprev/2.select— the table is traversed by callingselect/3andselect/1. The optionn_objectsdetermines the number of objects returned (that's the third argument ofselect/3); the default is to return 100 objects at a time. The match specification (the second argument ofselect/3) is assembled by QLC: simple filters get translated into equivalent match specifications, while the more complicated filters must be applied to all objects returned byselect/3given a match specification that matches all objects.{select, MatchSpec}— same asselect, the table is traversed by callingselect/3andselect/1. The difference? The match specification is explicitly specified. This is how you state match specifications that can't easily be expressed within the syntax that QLC provides.
Examples:
Here an explicit match specification is used to traverse the table:
1> T = ets:new(t, []).
2> ets:insert(T, [{1, a}, {2, b}, {3, c}, {4, d}, {5, e}]).
3> MS = ets:fun2ms(fun({X, Y}) when X > 1 andalso X < 5 -> {Y} end).
4> QH1 = ets:table(T, [{traverse, {select, MS}}]).And here's an example with an implicit match specification:
1> T = ets:new(t, []).
2> ets:insert(T, [{1, a}, {2, b}, {3, c}, {4, d}, {5, e}]).
true
3> is_tuple(qlc:q([{Y} || {X, Y} <- ets:table(T), X > 1 andalso X < 5])).
trueThe latter example is equivalent to the former, which you can verify using the function qlc:info/1:
1> T = ets:new(t, []).
2> ets:insert(T, [{1, a}, {2, b}, {3, c}, {4, d}, {5, e}]).
true
3> MS = ets:fun2ms(fun({X, Y}) when X > 1 andalso X < 5 -> {Y} end).
4> QH1 = ets:table(T, [{traverse, {select, MS}}]).
5> QH2 = qlc:q([{Y} || {X, Y} <- ets:table(T), X > 1 andalso X < 5]), qlc:info(QH1) =:= qlc:info(QH2).
trueqlc:info/1 returns information about a query handle, and in this case identical information is returned for the two query handles. Twin behavior fr fr. ✨
🦋 take(Table, Key) -> [Object]
take(Table, Key) -> [Object]
when Table :: table(), Key :: term(), Object :: tuple().Returns and removes a list of all objects with key Key in table Table. Yeah, she takes. And she doesn't give back. 💅
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 the details on the difference, go peek at lookup/2 and new/2).
✨ Examples ✨
1> T = ets:new(t, []), true = ets:insert(T, {k,1}), [{k,1}] = ets:take(T, k), [] = ets:lookup(T, k).
[]See how ets:lookup(T, k) comes back empty? Yeah. Taken. Gone. Not a trace. 😭
🧚 test_ms(Tuple, MatchSpec) -> {ok, Result} | {error, Errors}
test_ms(Tuple, MatchSpec) -> {ok, Result} | {error, Errors}
when
Tuple :: tuple(),
MatchSpec :: match_spec(),
Result :: term(),
Errors :: [{warning | error, string()}].This function is a little utility for testing a match specification used in calls to select/2. She does two jobs at once: she tests MatchSpec for "syntactic" correctness and runs that match specification against the 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, the tuple {error, Errors} is returned, where Errors is a list of natural language descriptions of what was wrong with the match specification. She'll tell you exactly what's up, in plain words, no cryptic nonsense. 🫶
This is a genuinely useful debugging and test tool, especially when you're out here writing complicated select/2 calls. Save yourself the pain bestie.
See also: erlang:match_spec_test/3.
✨ Examples ✨
1> MS = ets:fun2ms(fun({a,N}) -> N end), {ok,1} = ets:test_ms({a,1}, MS).
{ok,1}🍓 to_dets(Table, DetsTab) -> DetsTab
to_dets(Table, DetsTab) -> DetsTab
when Table :: table(), DetsTab :: dets:tab_name().Fills an already created/opened Dets table with all the objects from the already opened ETS table named Table. And watch out — the Dets table gets emptied before the objects are inserted. So whatever was in there before? Gone. Consider yourself warned. 💀
✨ Examples ✨
1> File = "ets_to_dets_example.dets".
"ets_to_dets_example.dets"
2> T = ets:new(t, []).
3> ets:insert(T, {k,1}).
true
4> {ok,_} = dets:open_file(ets_to_dets_example, [{file, File}]).
{ok,ets_to_dets_example}
5> ets_to_dets_example = ets:to_dets(T, ets_to_dets_example).
ets_to_dets_example
6> dets:lookup(ets_to_dets_example, k).
[{k,1}]
7> ok = dets:close(ets_to_dets_example), ok = file:delete(File).
okupdate_counter(Table, Key, UpdateOp | Incr | [UpdateOp], Default) ->
Result | [Result]
when
Table :: table(),
Key :: term(),
UpdateOp ::
{Pos, Incr} |
{Pos, Incr, Threshold, SetValue},
Pos :: integer(),
Incr :: integer(),
Threshold :: integer(),
SetValue :: integer(),
Result :: integer(),
Default :: tuple().Okay bestie, this is the glow-up version of the counter-updating function ✨ It's the same efficient, no-lookups-needed way to bump your counters, but it also lets you hand over a Default object, so if the key isn't in the table yet, boom 💥 — you still get your counter, no extra round trip, no drama.
It gives you a super efficient way to update one or more counters, without the whole tragic saga of looking up an object, incrementing an element, and inserting the object back into the table again 😭 The operation is guaranteed to be atomic and isolated. Periodt.
It destructively updates the object with key Key in table Table by adding Incr to the element at position Pos. The new counter value is returned. If no position is specified, the element directly following the key (<keypos>+1) is updated 💅
If a Threshold is specified, the counter gets reset to the value SetValue whenever these conditions hit:
Incris not negative (>= 0) and the result would be greater than (>)Threshold.Incris negative (< 0) and the result would be less than (<)Threshold.
You can pass a list of UpdateOp to do a whole bunch of update operations inside the same object 🎀 The operations are carried out in the order specified in the list. And if the same counter position shows up more than once in that list — no worries — that counter just gets updated many times, each time building on the previous result. The return value is a list of the new counter values from each update operation, in the same order as the operation list 🌸 If an empty list is specified, nothing is updated and you get an empty list back. And if the function fails? No updates are done. Zero. Nada. 💀
The specified Key is used to identify the object by either matching the key of an object in a set table, or comparing equal to the key of an object in an ordered_set table (for the deets on the difference, go peep lookup/2 and new/2, iykyk).
If a default object Default is specified, it's used as the object to be updated when 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 never been used, that is, a single updated element or a list of them. And heads up: an invalid default object will fail the function even if the key exists in the table 🚨
The function fails with reason badarg in these situations:
- The table type is not
setorordered_set. - No object with the correct key exists and no default object was supplied.
- The object has the wrong arity.
- The default object is not a tuple with an arity of at least
<keypos>of the table. - Any field from the default object that is updated is not an integer.
- The element to update is not an integer.
- The element to update is also the key.
- Any of
Pos,Incr,Threshold, orSetValueis not an integer.
✨ Examples ✨
1> T = ets:new(t, []), 5 = ets:update_counter(T, c, 5, {c,0}).
5Look at her go 🦋
update_element(Table, Key, ElementSpec, Default) -> boolean()
when
Table :: table(),
Key :: term(),
ElementSpec :: {Pos, Value} | [{Pos,
Value}],
Pos :: pos_integer(),
Value :: term(),
Default :: tuple().Now this one gives you an efficient way to update one or more elements inside an object, without the suffering of having to look up, update, and write back the entire object 🙈 Main character energy, lowkey.
It destructively updates the object with key Key in table Table. The element at position Pos is given the value Value. Simple. Iconic. 💅
You can pass a list of {Pos,Value} to update many elements inside the very same object 🌈 If the same position shows up 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. And 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 comparing equal to the key of an object in an ordered_set table (again, for the differences, see lookup/2 and new/2 — read the lore bestie).
If a default object Default is specified, it's 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. And yes, same warning as before: an invalid default object will fail the function even if the key exists in the table ⚠️
The function fails with reason badarg in these situations:
- The table type is not
setorordered_set. Pos < 1.Pos >object arity.- The default object is not a tuple with an arity of at least
<keypos>of the table. - The element to update is also the key.
✨ Examples ✨
1> T = ets:new(t, []), true = ets:update_element(T, k, {2,99}, {k,0}), [{k,99}] = ets:lookup(T, k).
[{k,99}]Ate. No crumbs. 🍓
whereis(TableName) -> tid() | undefined when TableName :: atom().This function returns the tid/0 of the named table identified by TableName, or undefined if no such table exists. The tid/0 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 ⚡
Another reason for using whereis/1 is to make sure a sequence of calls are accessing the same table even if the table is (concurrently) deleted and recreated with the same name 🙈 Because when the table is deleted, its tid/0 will be invalid even if another table is created with the same name. Not me getting attached to a tid that's already gone 💀
✨ Examples ✨
1> wtab = ets:new(wtab, [named_table]), true = (ets:whereis(wtab) =/= undefined).
trueAnd that's the whole page bestie, you made it to the very end 🎀🫶 This lil' saga is brought to you by Ericsson AB, running stdlib 8.0.4 — like the footer girlies at the bottom of the page would say. Go forth and ets responsibly, mwah 💜✨
📦 where this page comes from
- ubuntu stonking: erlang-doc 1:29.0.6+dfsg-1 · Apache-2.0
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms