This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-23
Channels
- # aatree (72)
- # aws (12)
- # beginners (34)
- # boot (256)
- # braid-chat (12)
- # cider (20)
- # clara (8)
- # cljs-dev (1)
- # cljsjs (1)
- # cljsrn (38)
- # clojure (61)
- # clojure-dev (10)
- # clojure-ireland (1)
- # clojure-japan (1)
- # clojure-sg (2)
- # clojurescript (48)
- # community-development (3)
- # conf-proposals (3)
- # core-async (6)
- # cursive (8)
- # datomic (4)
- # emacs (9)
- # hoplon (1)
- # leiningen (1)
- # mount (9)
- # off-topic (4)
- # om (109)
- # parinfer (26)
- # perun (4)
- # proton (5)
- # reagent (14)
- # vim (3)
@pguillebert: that's a very good question we haven't come to a strong conclusion on that front
right now, we are grabbing tables from postgres (configuration), importing them and using datascript to "enrich" our base set of facts
so we might have some basic idea of what IsClean
means, but we'll enrich that fact with :cleanliness-threshold :low
based on the information from the external configuration DB
obviously we've punted on guaranteeing we aren't affected by upstream schema changes for the moment
i'd like to talk about the configuration problem in general. we're going to need to have versioned rules per customer, likely with some kind of function registry, which may be as stupid as associating a set of versioned rules with a pointer to a git SHA where a particular file at that SHA is the mapping of our application's private functions, to the "public" functions that rules authors indirectly tap into when building rules