Support for caching the output of rule right-hand-side (RHS) activations so it can be replayed across rules sessions instead of recomputed.
The engine consults a cache the caller supplies via the :activation-cache
fire-rules option: an atom wrapping any clojure.core.cache/CacheProtocol implementation.
A rule opts in via its own :cache prop. This namespace provides
build-cache-key, which derives the key an activation is cached under (callers
can override it per fire with the :activation-cache-key-fn fire-rules option). Any
policy beyond basic lookup/hit/miss — TTL, tracking which entries were
consulted, sweeping at the end of a run — is the responsibility of the caller's
cache implementation.
Support for caching the output of rule right-hand-side (RHS) activations so it can be replayed across rules sessions instead of recomputed. The engine consults a cache the caller supplies via the `:activation-cache` fire-rules option: an atom wrapping any `clojure.core.cache/CacheProtocol` implementation. A rule opts in via its own `:cache` prop. This namespace provides `build-cache-key`, which derives the key an activation is cached under (callers can override it per fire with the `:activation-cache-key-fn` fire-rules option). Any policy beyond basic lookup/hit/miss — TTL, tracking which entries were consulted, sweeping at the end of a run — is the responsibility of the caller's cache implementation.
(build-cache-key {:keys [node token]})Builds an activation cache key for the given activation (a map with :node and
:token).
The key is the data the RHS output depends on: the rule's name, conditions
(:lhs), right-hand side (:rhs), environment, and props, plus the matched
facts and the bindings it fired on. Because the rule logic (:lhs/:rhs) and
the caller-supplied :name/:props are part of the key, it changes exactly
when the rule logic or its inputs change. The full bindings are stored (not a
hash) so a deserialized key compares = to a freshly-computed one with no
chance of collision.
Builds an activation cache key for the given activation (a map with `:node` and `:token`). The key is the data the RHS output depends on: the rule's name, conditions (`:lhs`), right-hand side (`:rhs`), environment, and props, plus the matched facts and the bindings it fired on. Because the rule logic (`:lhs`/`:rhs`) and the caller-supplied `:name`/`:props` are part of the key, it changes exactly when the rule logic or its inputs change. The full bindings are stored (not a hash) so a deserialized key compares `=` to a freshly-computed one with no chance of collision.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |