This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-14
Channels
- # admin-announcements (283)
- # announcements (1)
- # aws (3)
- # beginners (24)
- # cider (32)
- # clara (13)
- # cljs-dev (1)
- # cljsjs (10)
- # cljsrn (24)
- # clojure (179)
- # clojure-dev (6)
- # clojure-russia (149)
- # clojurecup (5)
- # clojurescript (33)
- # cursive (23)
- # datomic (35)
- # devops (6)
- # emacs (1)
- # jobs-rus (11)
- # ldnclj (77)
- # lein-figwheel (1)
- # luminus (3)
- # off-topic (3)
- # om (179)
- # onyx (13)
- # proton (6)
- # reagent (60)
- # testing (1)
@ryanbrush: so, i suspect this might be considered out of scope for clara, but all the same: any thoughts on rule persistence/versioning? for instance, i might receive rules over the wire.
if this is the case, I may need to for instance, make a function registry so functions within the LHS or RHS are resolvable when I read them in
is this something you or anyone else following along has dealt with? what'd you choose as a method of versioning and mapping rule logic?
@devn We just keep rules in source control and it let it handle versioning. I'd imagine a variety of content management systems would be up to the task. As for a function registry, I just use fully-qualified function names from a library, and just have rules depend on a specific library version to use those functions. So not so much as a "function registry" as just using a versioned dependency JAR and qualified function names.
@devn Of course, a more sophisticated solution could be built, but I've found just using source control and dependency management sufficient for our needs. And, as you know, Clara rules are just data structures that could be stored wherever convenient.