Raw wall-clock read in epoch milliseconds. Dynamic ONLY so tests can simulate clock retreat; never rebind in production.
Raw wall-clock read in epoch milliseconds. Dynamic ONLY so tests can simulate clock retreat; never rebind in production.
(invoke-write-hooks! store hook-event)Invoke all registered write hooks with the operation details. Hooks are called synchronously after a successful write.
Invoke all registered write hooks with the operation details. Hooks are called synchronously after a successful write.
(kv-keys kvs)The keys of a multi-assoc kvs argument, which may be a map OR an ORDERED
sequence of [k v] pairs (see konserve.core/multi-assoc). For a pair-seq the
key order is preserved; for a map it is unspecified, as always.
The keys of a `multi-assoc` kvs argument, which may be a map OR an ORDERED sequence of [k v] pairs (see `konserve.core/multi-assoc`). For a pair-seq the key order is preserved; for a map it is unspecified, as always.
(meta-update key type old)Metadata has following 'edn' format {:key 'The stored key' :type 'The type of the stored value binary or edn' :last-write Date timestamp in milliseconds.} Returns the meta value of the stored key-value tuple. Returns metadata if the key value not exist, if it does it will update the last-write to date now.
Metadata has following 'edn' format
{:key 'The stored key'
:type 'The type of the stored value binary or edn'
:last-write Date timestamp in milliseconds.}
Returns the meta value of the stored key-value tuple. Returns metadata if the key
value not exist, if it does it will update the last-write to date now. (monotonic-now-ms)Monotonic (non-decreasing) timestamp in epoch milliseconds:
max(wall-clock, previous-stamp).
A monotone hold on the wall clock: stamps read as wall time under normal
operation and NEVER go backwards — an NTP step-back, VM suspend/resume or
manual clock set holds the stamp flat at the previous value until real
time catches up. Deliberately NOT strictly increasing (no +1 per stamp):
under sustained write rates above 1000 stamps/second a strict clock would
run ahead of physical time — and after a restart following a bulk import,
the re-seeded wall clock would sit BELOW the persisted stamps, stalling
collection until real time caught up. Garbage collection only needs a
monotonic order: the sweep spares objects whose stamp EQUALS the cutoff,
so same-millisecond ties are fail-safe (garbage retained one cycle, never
a live object deleted). Restarts re-seed from the wall clock; a retreat
across a restart likewise only retains garbage longer.
All konserve write stamps and any collector comparing against them MUST read this one source: happens-before between a guard acquisition and the writes it covers is then literal in the stamps, instead of an assumption about the machine clock.
Monotonic (non-decreasing) timestamp in epoch milliseconds: `max(wall-clock, previous-stamp)`. A monotone hold on the wall clock: stamps read as wall time under normal operation and NEVER go backwards — an NTP step-back, VM suspend/resume or manual clock set holds the stamp flat at the previous value until real time catches up. Deliberately NOT strictly increasing (no `+1` per stamp): under sustained write rates above 1000 stamps/second a strict clock would run ahead of physical time — and after a restart following a bulk import, the re-seeded wall clock would sit BELOW the persisted stamps, stalling collection until real time caught up. Garbage collection only needs a monotonic order: the sweep spares objects whose stamp EQUALS the cutoff, so same-millisecond ties are fail-safe (garbage retained one cycle, never a live object deleted). Restarts re-seed from the wall clock; a retreat across a restart likewise only retains garbage longer. All konserve write stamps and any collector comparing against them MUST read this one source: happens-before between a guard acquisition and the writes it covers is then literal in the stamps, instead of an assumption about the machine clock.
(multi-key-capable? store)Checks whether the store supports multi-key operations.
This function is used by the high-level API to determine if a store supports multi-key operations.
Checks whether the store supports multi-key operations. This function is used by the high-level API to determine if a store supports multi-key operations.
(now)Monotonic wall-clock Date — see monotonic-now-ms. Stamped into every
key's :last-write metadata; konserve.gc/sweep! and external collectors
(e.g. datahike's gc-guard safe-point) compare against these stamps and
must obtain their cutoffs from THIS function, not a raw clock read.
Monotonic wall-clock Date — see `monotonic-now-ms`. Stamped into every key's `:last-write` metadata; `konserve.gc/sweep!` and external collectors (e.g. datahike's gc-guard safe-point) compare against these stamps and must obtain their cutoffs from THIS function, not a raw clock read.
(write-hooks-capable? store)Checks whether the store supports write hooks.
This function is used by the high-level API and compliance tests to determine if a store supports the PWriteHookStore protocol.
Checks whether the store supports write hooks. This function is used by the high-level API and compliance tests to determine if a store supports the PWriteHookStore protocol.
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 |