Hi Joachim, What you're describing is a dynamic system map, whereas the current pattern as described by Stuart in his classic blog post http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloadeddescribes a static system map which is established at the beginning of a reset cycle and remains. After all, it's a var, not an atom. The reset pattern is intended as a development aid, with the bonus of providing some architectural hygiene that comes in having system state located in a single map (rather than as vars spread over many namespaces). There is no intention to reset a production system.
However, there's no reason why you can't put an atom or ref in the system map, have that atom or ref updated every time the config changes, and connect everything together with core.async. Parts of your program that need up-to-date configuration details can deref the atom or ref, just in time, or watch the atom or ref in order to trigger database re-connections. You definitely shouldn't be altering the global var root which contains the system, as suggested in 2. You shouldn't access user/system in your program code (although it's a useful thing to access in an exploratory REPL). Instead, a component should pass the system it receives in the start phase as an argument when building structures, such as Ring middle-ware chains, connection managers, thread pools, etc. Regards, Malcolm On 11 March 2014 15:17, Joachim De Beule <joachim.de.be...@gmail.com> wrote: > update: I made mistake at the end of my previous post: I mean "that the db > component does NOT sufficiently encapsulate the internals" of course... > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/E0BdR_AksiA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
