This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-01
Channels
- # announcements (1)
- # babashka (1)
- # beginners (49)
- # calva (111)
- # chlorine-clover (2)
- # cider (2)
- # circleci (9)
- # clojure (60)
- # clojure-europe (25)
- # clojure-nl (4)
- # clojure-taiwan (2)
- # clojure-uk (10)
- # code-reviews (5)
- # conjure (1)
- # cryogen (2)
- # cursive (1)
- # data-science (1)
- # datomic (1)
- # figwheel-main (1)
- # fulcro (23)
- # hoplon (2)
- # malli (4)
- # meander (1)
- # off-topic (149)
- # other-languages (1)
- # re-frame (40)
- # reagent (27)
- # reitit (2)
- # shadow-cljs (25)
- # slack-help (4)
- # spacemacs (7)
- # xtdb (11)
Might be less confusing for folks who are new to Clojure if they’re commented out anyway? :woman-shrugging:
Actually nothing gets persisted by default. Everything is in-memory by default. You have to specify all the configuration (RocksDB, Kafka or whatever) explicitly in the call to start-node
and include the relevant modules via your classpath deps
I hate to be That Guy, but why :in replacing :args? I understood the semantics of :args at this point, I'm still trying to wrap my head around :in
I sympathise 🙂 :in
was certainly more complex to grasp at first, but :args
is much less powerful and keeping both approaches around for the long-term would only complicate things further. Specifically, the benefit is that the inputs provided via :in
are handled as first-class relations, whereas to achieve the same effect with :args
the user has to generate the cartesian products of all possible input combinations before handing them to the query engine (which could be prohibitively large for certain kinds of queries). In many scenarios :in
will avoid a lot of work for the user and for the query engine compared to the :args
alternative