Cachex v3.1.3 Cachex.Warmer behaviour View Source

Module controlling cache warmer behaviour definitions.

This module defines the cache warming implementation for Cachex, allowing the user to register warmers against a cache to populate the tables on an interval. Doing this allows for easy pulling against expensive values (such as those from a backing database or remote server), without risking heavy usage.

Warmers are fired on a schedule, and are exposed via a very simple behaviour of just an interval and a block to execute on the interval. It should be noted that this is a moving interval, and it resets after execution has completed.

Link to this section Summary

Callbacks

execute(state)

Executes actions to warm a cache instance on interval

interval()

Returns the interval this warmer will execute on

Link to this section Callbacks

execute(state)

execute(state :: any()) ::
  :ignore
  | {:ok, pairs :: [{key :: any(), value :: any()}]}
  | {:ok, pairs :: [{key :: any(), value :: any()}], options :: Keyword.t()}

Executes actions to warm a cache instance on interval.

This can either return values to set in the cache, or the atom :ignore to signal that there’s nothing to be set at this point in time. Values to be set should be returned as { :ok, pairs } where pairs is a list of { key, value } pairs to place into the cache via Cachex.put_many/3.

If you wish to provide expiration against the keys, you can return a Tuple in the form { :ok, pairs, opts } where opts is a list of options as accepted by the Cachex.put_many/3 function, thus allowing you to expire your warmed data. Unless this is provided, there is no explicit expiration associated with warmed values (as predicting the appropriate expiration is not possible).

The argument provided here is the one provided as state to the warmer records at cache configuration time; it will be nil if none was provided.

interval()

interval() :: integer()

Returns the interval this warmer will execute on.

This must be an integer representing a count of milliseconds to wait before the next execution of the warmer. Anything else will cause either invalidation errors on cache startup, or crashes at runtime.