roger v2.4.0 Roger.KeySet View Source
An opaque interface to storing keys and testing set member ship of keys. Like a bloom filter, but 100% probabilistic.
iex> {:ok, pid} = Roger.KeySet.start_link
iex> Roger.KeySet.add(pid, "bla")
:ok
iex> Roger.KeySet.contains?(pid, "bla")
true
iex> Roger.KeySet.contains?(pid, "beh")
false
Keys can also be removed:
iex> {:ok, pid} = Roger.KeySet.start_link
iex> Roger.KeySet.add(pid, "bla")
iex> Roger.KeySet.remove(pid, "bla")
:ok
iex> Roger.KeySet.contains?(pid, "bla")
false
The state of the keyset can be retrieved in binary format. This state is to be treated as an opaque datastructure. We can then load the state into a new keyset process.
The state can also be given as an argument when the keyset process is started.
iex> {:ok, pid} = Roger.KeySet.start_link
iex> Roger.KeySet.add(pid, "existing")
iex> {:ok, state} = Roger.KeySet.get_state(pid)
iex> {:ok, pid2} = Roger.KeySet.start_link(state: state)
iex> Roger.KeySet.contains?(pid2, "existing")
true
Many keys can also be added at once:
iex> {:ok, pid} = Roger.KeySet.start_link
iex> Roger.KeySet.add_many(pid, ~w(a b c))
:ok
iex> Roger.KeySet.contains?(pid, "a")
true
iex> Roger.KeySet.contains?(pid, "b")
true
iex> Roger.KeySet.contains?(pid, "c")
true
Two keysets can also be used in set operations. These will always be applied to the first keyset; the second is left untouched:
iex> {:ok, a} = Roger.KeySet.start_link
iex> Roger.KeySet.add_many(a, ~w(a1 a2 a3))
iex> {:ok, b} = Roger.KeySet.start_link
iex> Roger.KeySet.add_many(b, ~w(b1 b2))
iex> Roger.KeySet.union(a, b)
:ok
iex> Roger.KeySet.contains?(a, "b1")
true
iex> Roger.KeySet.contains?(b, "a1")
false
iex> Roger.KeySet.difference(a, b)
:ok
iex> Roger.KeySet.contains?(a, "b1")
false
Note: the current implementation is a MapSet but this is an implementation detail and likely to change.
Link to this section Summary
Functions
Returns a specification to start this module under a supervisor
Invoked when the server is started. start_link/3
or start/3
will
block until it returns
Link to this section Functions
Returns a specification to start this module under a supervisor.
See Supervisor
.
Invoked when the server is started. start_link/3
or start/3
will
block until it returns.
args
is the argument term (second argument) passed to start_link/3
.
Returning {:ok, state}
will cause start_link/3
to return
{:ok, pid}
and the process to enter its loop.
Returning {:ok, state, timeout}
is similar to {:ok, state}
except handle_info(:timeout, state)
will be called after timeout
milliseconds if no messages are received within the timeout.
Returning {:ok, state, :hibernate}
is similar to {:ok, state}
except the process is hibernated before entering the loop. See
c:handle_call/3
for more information on hibernation.
Returning {:ok, state, {:continue, continue}}
is similar to
{:ok, state}
except that immediately after entering the loop
the c:handle_continue/2
callback will be invoked with the value
continue
as first argument.
Returning :ignore
will cause start_link/3
to return :ignore
and
the process will exit normally without entering the loop or calling
c:terminate/2
. If used when part of a supervision tree the parent
supervisor will not fail to start nor immediately try to restart the
GenServer
. The remainder of the supervision tree will be started
and so the GenServer
should not be required by other processes.
It can be started later with Supervisor.restart_child/2
as the child
specification is saved in the parent supervisor. The main use cases for
this are:
- The
GenServer
is disabled by configuration but might be enabled later. - An error occurred and it will be handled by a different mechanism than the
Supervisor
. Likely this approach involves callingSupervisor.restart_child/2
after a delay to attempt a restart.
Returning {:stop, reason}
will cause start_link/3
to return
{:error, reason}
and the process to exit with reason reason
without
entering the loop or calling c:terminate/2
.
Callback implementation for GenServer.init/1
.