Couple of questions 1) I see there is no "update!" --- is retract! followed by insert! considered non-idiomatic?

In general, updating a fact would make truth maintenance really hard, if not impossible. If you find yourself retracting and inserting a fact on a right-hand-side, you are probably also going to run afoul of truth maintenance, likely by creating an infinite loop.

Logically, if a fact is no longer true because of a new piece of data, you should have an additional condition on the left-hand-side of the original rule.

Which allows truth maintenance to clear it up.

2) I have a case where I take measurements of events something like {"eventX" [ (:limit 5 :prior (5 hrs)) (:limit 10 :prior (1 day)) ]} also I need to +1 those measures if they just now happened based on rule. (I don't have a list of events over that time, just the prior totals) I'm guessing the short answer is I need to "normalize the list" into individual facts and leverage insert-all! as well as use an accumulator (prior total + 1?), but then I need to accumulate and match against the limit, and how to do this with a flexible list is the part I'm not currently seeing. Particularly totaling over each period to compare against limit.

I would absolutely break down the measurements into independent facts.

I'm not sure how you are saying :prior works. Do you want a rule to fire a rule if you get an event more than :limit in the last :prior?

so there's the existing count (from DB) if that count + (just now happened) > limit fire rule.

You've inserted multiple facts that has the database count of events of a particular type?

i can do that... currently the logic is the LHS side fetches the info (uses cache)

(java call)

the final piece is maybe something like [ EventCount (?name name)(?limit limit)(?period period) (>= ?limit ( accumulate total for ?period ?name)) ; pseudocode

but then accumulating will be redundant.

Assuming you aren't using an immutable, global database, you will likely have trouble with consistency if you put database calls on the left-hand-side.

(the cache fixes that part, only refetches for another session)

but that doesn't give me a flexible list of periods

You have access to the session on the left-hand-side?

(in a rule at all, in fact?)

no... its a java bean inserted into WM

what's a WM?

but a new one for each ... sorry firing. (working memory : clara currently drools 🙂 )

basically the bean is inserted before fire rules.

ah, right. But this will have the consistency issue I'm talking about. If the count changes in the database, it will not refire a rule.

not an issue.

it caches the call and keeps it for rest of that firing.

and that's acceptable.

Ahhh, I see.

It presents an immutable snapshot to the session. That's kind of neat.

but currently we write rules and add to them if we add more periods, that sort of thing... rather have the list of periods flexible and rules take care of.

I think I need two defrecords one for name/period combo and another for keeping the count?

so match on all periods records and accumulate on the counting records (i think).

i think i was trying to keep this all kind of in one structure, and that's not do-able.

I think doing arbitrary, data-driven periods will be hard without generating rules from data.

Well, maybe not the way you are doing it.

yeah, i'm going to see what that looks like if I can get it working refine from there... Thanks!