Closed yatesco closed 4 years ago
Actually, is the answer simply to change the order of require
s? It never occurred to me that the order would be honoured....assumptions and all that :-)
yea, in the namespace (where the "system" is created/started) mount will start components based on the order compiler sees them. for example:
(ns app
(:require [foo.bar :as fbar]
[foo.baz :as fbaz]))
(defn start-system []
;; ...
)
components in fbar
will start first.
unless fbar
also requires fbaz
:)
Thanks all - closing this. TIL that the order of requires matters :-)
(I know what the right answer is, which is to declare compile time dependencies on all pre-requisites but this is sometimes impractical ;-)).
Prior to
mount
I used a blunt approach:this worked well for a few hundred components and had the very nice property that the sequence of boot up was clear and always correct (as the compiler forced dependencies to be defined before they were used).
However, then I needed to patch some of the data structures in the DB before the rest of the system started up, so they trivially went at the top of the
let
block:thing-1
didn't have any code API dependency on the patch but they did assume the patches had run and therefore expected the new patched shapes out of the DB.Equally, there are some
bootstrap
activities (setting default JVM to Timezone to UTC etc.) which again, all went in the appropriate sequence instart-system
.My assertion is that it is impractical for each component to add a compile dependency on every single thing it assumes has happened (i.e. the bootstrap and patches).
It is also more complex as some of those patches (for example) actually use
thing-X
s.I have since introduced
mount
and changed thestart-system
to:(where
component
is(defstate component...
in the component'sns
)but
thing-X
is starting before thebootstrap
andpatches
.It would be great if it was possible to annotate
defstate
to indicate "start this as early as possible" which could be optionally parameterised with a numerical sequence. Then I could:bootstrap
to start at 0patches
(which may well depend onthing-X
!) to start at 10Another approach I considered, which doesn't solve the problem but does make it more digestible, would be to have coarser grained subsystems, so:
bootstrap
subsystempatch
subsystem which has a compile time dependency onbootstrap
components
subsystem which has a compile time dependency onpatch
, and for explicitnessbootstrap
thing-X
components within thecomponents
subsystemI dunno :-) - just reporting a real use-case I ran into which I don't have the brainpower to see my way through with
mount
:-).