You could just accumulate Foo(s) and pick latest if you really need to have all Foos in memory, but maybe you could just only run rules with the latest Foo and not keep around a long running Session object?

I do need a long-running session object — the system is processing thousands of websocket updates every second, and after each update I only need the latest version of the system. That’s why I want to discard all older versions of Foo after each new Foo. @U07MK6PLN

I don't think sharing a session object across thousand of connections would be a good idea, maybe you can work around that constraint with locking and other methods, but using a session like a long-running database might not be a good idea, what happens if your container has to restart? also when you are constantly inserting facts into a long running session it will continuously grow larger, if you are talking thousands of times per second you might find yourself eventually running out of memory. Maybe try using unconditional retractions to see if that fits your use case, but beware, you're basically bypassing truth maintenance if you're doing that.

I never said anything about sharing, it’s all happening in one thread, sequentially.

alright, try that then, using unconditional retractions or accumulating both should sort of "work"

I don’t understand how to do it:)

I would typically try to have the retracting be done outside of the rules and then just fire rules again after

Things can get complicated though, if that retraction would just cause every rule to have to reevaluate and not reuse any state

A lot depends on what the real flow is, and what this fact means to the rule set

It’s very similar to tracking a players position in x/y axis. I’m getting separate updates for each player with either new x, new y or both and update the positions in the system. I don’t need to store history of their movements. Something like this.

based on what you are describing you could just store player position in a hash-map, then feed the hash-map to the rules engine as a fact, and run rules based on that.

That’s an interesting approach, thank you! So I’ll have one run of all the rules, then use the results? Cool

exactly, yeah

Makes it simpler to reason about too. Thanks!