Retraction presents some edge cases that aren't trivial but it's solvable in group-by similar to how we do it in other accumulators. Notice the all accumulator takes care to only remove what is retracted, for instance. Group-by is more complicated but I think a suitable approach would work.

Gotcha. Thanks.

@ryanbrush: as long as I've got you here: something that's been on my mind that I think I remember reading something on the ML about is: How much can I rely on storing rules in a database, what about sessions? We've been toying with the idea of exposing some level of rule authorship at some point in the future, but either way, we are going to have differing sets of rules, some of which will be generated based on configuration data.

Other random things on my mind: 1.) I've been reading about Jess and Drools, and they have a collect or collectBy IIRC. Since map can be written in terms of reduce, is it reasonable to say that Clara has collect by way of its accumulate? Is all basically collect? 2.) Do you have any suggested reading? I am occasionally flop-sweating a bit over whether or not I should reach for an accumulator, for instance. This is my first time working with a rules engine, and so I am still sort of in the hunting and pecking phase. Not entirely confident.

I don't see any problem with storing rules or externally or generating them, and mixing those rules with hand-written rules. mk-session supports multiple inputs that can pull rules in from multiple heterogenous sources. Note that to load new rules you need to create a new session...you can't add or update rules to a session that has already been created.

As for collect and collectBy, it's been a while since I've used Drools but I believe they are basically just the all accumulator (or some other special accumulator case).

As for recommended reading, most of what I've found lately subscribes to the approach of rules-for-business-users rather than directed at engineers, so there's not much out there. I think designing rules just follows the best practices for designing code: take the simplest, most clear, and least surprising approach possible...and iterate to improve it.

@ryanbrush: yeah, we're pulling from multiple sources right now. I guess the big question was: as of right now, do you foresee any future compatibility issues with storing the value of a defrule. Like, if 1.0 changed to having :lhs {:different [] :stuff []}

No, I think the schema for the defrule and defquery value is pretty much locked down.

Any changes there would be non-breaking (like we might add properties for activation groups or things like that). But that basic structure of a rule is pretty fundamental to the system, so I don't see it changing.

@ryanbrush: good common sense advice. i would hope we're meeting our obligation to keep things clean, but in some cases I question whether I'm taking the "easy" route over the "simple" route, simply because I don't know what I don't know.

@devn Haha, I feel that way every day I wrote code!

heh, yeah, kind of a universal problem

btw @ryanbrush -- i dropped you a PM

@devn By the way, what do you think about changing the URL for this group to http://www.clara-rules.org/ ? It's a bit cleaner and more accessible front door to Clara than the GitHub page.

Of course!

This is really your channel.