Hey @devn, a good rule of thumb is that Clara will have one activation for each unique combination of bound variables. So when you remove the ?date binding in that accumulator, it just grabs the latest for all records and fires once. If you add a binding in an accumulator, it accumulates separately for each binding (?date in this case) and fires once per unique binding.

Thanks for that explanation. I was thinking about the binding on ?date being a sort of bucketing/grouping operation, so for each bucket of unique ?date values, capture the greatest date.

using ?date there doesn't make much sense from a practical standpoint, since the accumulator pulls :date anyhow

Yeah, that's he idea.

@ryanbrush: a loaded question: any thoughts on multiple sessions vs a single, shared session?

If you need richer semantics, you can always access any fields in the resulting accumulated value in the RHS, or even use a custom accumulator. But that depends on the use case

my question is sort of intentionally vague

the big question is: are there common triggers in your mind for when to split out a new session using the results of queries on another session?

As for a single vs multiple sessions, just depends on what's easier to work with. We tend to use multiple sessions since there is very little overlap between them so it makes sense to keep separate. But YMMV.

But big sessions should perform pretty well, so whatever is simpler seems like a good starting point. We have sessions with 100k records and thousands of rules easily.

thinking out loud: i guess it's like namespacing or anything else, it's just that there is a pretty pipeline-ish feel to what we've built, and with the number of facts that are inserted for specific rule firings, it seems like there might be some valuable in splitting things out a bit more to make inspection easier

then again, from the standpoint of providing explanations, there's some overhead associated with passing those facts through to another session

since, for the purposes of a UI for instance, you need to capture the explanations from different sessions and cobble them together

not hard, really

just easier to have the single session

Yeah. The old loose coupling/high cohesion design trade offs never really go away.

Speaking of UIs... 😉

IIRC I think you said the tools.ui work is on hold/not gonna happen

Yeah, not much is going on in that space now. It hasn't been a big need for us, so other demands have moved up. Happy to work with others that might be interested though.

(Oops....Need to drop offline for a bit here, but will be back on later in the day.)

It hasn't been a big need for us either, but generally speaking, onboarding people who haven't worked with a rules engine could be easier. I've been thinking about whether it's a UI that I want, or if it's just better editor tooling to bring "focus" to specific rules, or parts of rules.

clara provides an opportunity to deliver good explanations. so, i wonder about a sort of meta-explain that could provide a more readable version of why a rule fired. I imagine in the above case seeing something like: For each DatedFact (of which there were 10), retrieve the latest fact for each unique ?foo value grouping. There were 3 unique ?foo values (`"A", "B", "C"`). As a result, 3 LatestFact facts were inserted into the session. Since you've requested I focus my attention on the date field of LatestFact in my summaries, these are the date values on LatestFact which were inserted: 2016-05-10, ...

I would of course settle for: "Me take DatedFact, put unique ?foo in many bucket, put LatestFact with date of 2016-05-10." 🙂

BTW, @mikerod && @ryanbrush -- Excited to see the work and thought going into session durability. Thank you.

devn: I'd echo sort of what Ryan said that smaller sessions can work alright. If you have heavy-weight logic in rules though, it is good to share that if it applies to many other sessions. One idea would be to just derive facts for the common logic in one session, and then insert those facts into another new session later. That isn't too expensive if the hard-work is in the rules that make those derived facts.

devn: And yes, the durability stuff will be coming along hopefully in a timely manner. I'm working on a prototype for it still currently and will keep design thoughts and discussions posted on the https://github.com/rbrush/clara-rules/issues/198 issue

If you have any input there on how you'd want it to work, I'd be interested to hear that too. I have a use-case in mind, but it is good to know if there are any differing needs. I had a really rough demo of some thoughts @ https://github.com/mrrodriguez/clara-durability-demo but that would not be the expected way everyone would need to interface. I was just toying with an idea of being able to use an extension point like clojure.core/print-dup to give hooks for serialization.

In our case, our working memory of the rules session will actually have different types of objects in them, like Java Serializable, Avro, Clojure records

So I am messing around with ideas on how to efficiently provide capabilities to serialize this data when the serialization formats of groups of the data points actually, likely needs to vary..