Fork me on GitHub
#clara
<
2020-08-11
>
defndaines14:08:06

We use one session per request, but that may be specific to our scenario, where each request represented a wholly unique patient.

lpanda201415:08:57

@defndaines thanks! any chance you’ve used the explain activations function in the tooling? i’m curious what the best way is to use that if each session is spun up and down for a request

defndaines16:08:54

We have a hook to turn on explain-activations, but we rarely use it. We accumulate data in each of our facts that helps with all of our debugging. We also capture all of the input to the sessions, so we can reproduce a session for debugging in order to analyze.

lpanda201416:08:44

thank you! that’s super helpful

mikerod19:08:23

So a session is immutable.

mikerod19:08:49

I would necessarily recommend making a new session when speed is important or it is slower due to many rules

mikerod19:08:54

With smaller rule sets maybe ok

mikerod19:08:41

But typically, I’d store the initial session made via mk-session and then just do new isolated insert+fire callls on it “per unrelated invocation”

mikerod19:08:25

This is also assuming the rule set is unchanged per use.

lpanda201419:08:16

thank you! much appreciated.