clara

http://www.clara-rules.org/
Joel 2019-04-19T02:20:20.001300Z

somebody have a starter project for spring boot, but with clara support?

Joel 2019-04-19T03:10:53.002500Z

also, what is attracting me to Clara is that I'm expecting i could "introspect" the rules relatively easily, possibly even modify dynamically --- is that a reasonable assumption?

Joel 2019-04-19T13:49:02.003100Z

no, not in that respect. I'm interested in reading the rules to see what data they are looking for, fetched, and put into working member before running. For DB/REST calls.

Joel 2019-04-19T13:51:51.003300Z

Basically, its an optimization so multiple calls aren't made while rules run, can do them all up front with single calls.

Joel 2019-04-19T13:59:07.003500Z

The second part, probably thinking about the wrong way, but for parts of the rules that have variables, I'd kind of like to see the rules served up with the variables replaced with actual values, so that it's easier to understand for user (developer). Basically I'll be serving up the rules from a server, and the server will also know what some of the vars should be in the rules, if server could basically inject that info, my thinking it's easier than having to reason about than having to look-up the values by hand. These variables change infrequently. Maybe server could inject them not necessarily inline so at least easy to see in one place. Hope that makes sense.

2019-04-22T14:58:56.009500Z

@joel380 The way to model what you are saying in the “second part” above, would be to make your variables expressed as facts instead.

2019-04-22T14:59:25.009700Z

That’s the typical way it’d be done and the most straightforward with the way the forward-chaining data flow of the rules engine works.

2019-04-22T14:59:43.009900Z

> if server could basically inject that info The “injection” would be to just insert these facts.

2019-04-22T15:00:24.010100Z

You base logic on them. If you need to derive things from them for other rules - derive “intermediate facts”, ie facts meant to just build up higher-level concepts to relay to other rules.

2019-04-22T15:01:39.010300Z

Remember, the working memory “session” state is immutable. So if you don’t want to continually put in these infrequently changed facts, you could potentially create a session, insert these facts only, then use that as your base session for other later independent memory states with the more frequently changing facts.

2019-04-24T08:52:14.034100Z

This will work and is probably easiest, but if you really want to have the values be determined statically note that Clara can build sessions from rule data structures that you pass it; rules/queries don't have to be created with the defrule/defquery macros. So you can have arbitrary generation logic. You can look at the schemas namespace and the data under rule/query vars for examples. It might be best to become familiar with code generation e.g. macros in Clojure if you go down this route though.

👍 1
2019-04-19T06:26:45.002700Z

What sorts of introspection did you have in mind? If you mean introspection on what the rules engine did and why, there's a good amount of that, you can take a look at the inspect namespace and if you wanted something lower level the tracing namespace. If you mean introspection on the rules network, possibly yes if you write things yourself, but since the rules can contain arbitrary code (that the user writes) you have the usual problems with inspecting arbitrary code.

2019-04-19T06:28:11.002900Z

Regarding dynamic modification, if you want to change the rules you have to build a new session and rerun the rules.