Which addons a reload actually touches — the pure Pipeline stratum of the hot-reload bridge. No IO, no var resolution, no host.
Reloading addon A is not enough. Every addon that received A's INSTANCE at
mount time (through the mounter's :mount/dependencies sibling injection)
still holds the pre-reload object; leaving them alone leaves the system half
old and half new, which is the same silent-corruption shape as a partial
namespace reload. So a reload seeds at the changed addons and closes forward
over the dependency graph.
The graph is NOT recomputed here: edges and solve come from
hive-addon.mount.solve, so the order a reload uses is the same order the
original mount used, produced by the same rule chain (and extended by the
same custom :rules).
Which addons a reload actually touches — the pure Pipeline stratum of the hot-reload bridge. No IO, no var resolution, no host. Reloading addon A is not enough. Every addon that received A's INSTANCE at mount time (through the mounter's `:mount/dependencies` sibling injection) still holds the pre-reload object; leaving them alone leaves the system half old and half new, which is the same silent-corruption shape as a partial namespace reload. So a reload seeds at the changed addons and closes forward over the dependency graph. The graph is NOT recomputed here: `edges` and `solve` come from hive-addon.mount.solve, so the order a reload uses is the same order the original mount used, produced by the same rule chain (and extended by the same custom `:rules`).
(affected-plan specs seed-ids)(affected-plan specs seed-ids opts)A MountPlan whose :ordered is the reload closure of seed-ids, in the SAME
global topological order the full mount used.
Built by solving the WHOLE spec set and then filtering :ordered down to the closure — never by solving the subset alone. Solving the subset would drop the ordering constraints contributed by specs outside it, so a dependent could be remounted before a dependency that merely happened not to be affected.
Diagnostics (:cycles, :missing, :unmet-capabilities, :duplicates) are carried through from the full solve, unfiltered: they describe the graph, not the slice.
opts is passed to solve (:rules, :fail-closed-cycles).
A MountPlan whose :ordered is the reload closure of `seed-ids`, in the SAME global topological order the full mount used. Built by solving the WHOLE spec set and then filtering :ordered down to the closure — never by solving the subset alone. Solving the subset would drop the ordering constraints contributed by specs outside it, so a dependent could be remounted before a dependency that merely happened not to be affected. Diagnostics (:cycles, :missing, :unmet-capabilities, :duplicates) are carried through from the full solve, unfiltered: they describe the graph, not the slice. opts is passed to `solve` (:rules, :fail-closed-cycles).
(dependents specs seed-ids)(dependents specs seed-ids {:keys [rules]})The transitive dependent closure of seed-ids within specs, INCLUDING the
seeds themselves.
Follows dependency edges forward: if B depends on A and C depends on B, then (dependents specs #{"A"}) is #{"A" "B" "C"}. Terminates on cycles because the frontier only ever advances into ids not already seen.
opts: {:rules [rule ...]} — the same OCP rule chain solve takes, so a custom
ordering rule contributes to the reload closure too.
The transitive dependent closure of `seed-ids` within `specs`, INCLUDING the
seeds themselves.
Follows dependency edges forward: if B depends on A and C depends on B, then
(dependents specs #{"A"}) is #{"A" "B" "C"}. Terminates on cycles because
the frontier only ever advances into ids not already seen.
opts: {:rules [rule ...]} — the same OCP rule chain `solve` takes, so a custom
ordering rule contributes to the reload closure too.(ns->addon-ids specs)Index {init-ns-string #{addon-id ...}} over specs.
A set, not a single id, because two addons legitimately share a constructor
namespace — hive.qdrant and hive.qdrant.kanban both construct from
hive-qdrant.addon. Reloading that namespace must seed BOTH.
Index {init-ns-string #{addon-id ...}} over `specs`.
A set, not a single id, because two addons legitimately share a constructor
namespace — `hive.qdrant` and `hive.qdrant.kanban` both construct from
`hive-qdrant.addon`. Reloading that namespace must seed BOTH.(seeds-for-ns specs ns-str)The addon ids whose constructor namespace is ns-str. Empty set when none.
The addon ids whose constructor namespace is `ns-str`. Empty set when none.
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 |