clara

licht1stein 2024-04-15T15:07:23.170869Z

Hi How do I implement a rule which only keeps one record of certain type with certain id in the memory? For example I have (defrecord Foo [id x y]), each time a new Foo is inserted with an id , the old ones should be retracted. I couldn’t find a way to do it so far, please help

jgomez 2024-04-15T17:35:42.657829Z

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?

licht1stein 2024-04-15T18:09:15.733189Z

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. @k13gomez

jgomez 2024-04-15T18:18:18.752449Z

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.

👍 1
licht1stein 2024-04-15T18:41:57.924539Z

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

jgomez 2024-04-15T18:43:39.094199Z

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

licht1stein 2024-04-15T18:46:54.905049Z

I don’t understand how to do it:)

2024-04-15T23:28:22.271019Z

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

2024-04-15T23:28:41.109179Z

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

2024-04-15T23:28:59.989789Z

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

jgomez 2024-04-17T13:55:25.975519Z

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.

licht1stein 2024-04-17T13:57:04.915039Z

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

jgomez 2024-04-17T13:57:22.506149Z

exactly, yeah

licht1stein 2024-04-17T13:57:54.408369Z

Makes it simpler to reason about too. Thanks!

licht1stein 2024-04-16T13:53:52.065849Z

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.