If I have a “UpdatingItem” that holds reference to the Item, it will have the same problem when attempting to capture its accumulation. If I hold some list of the “seen items” then modifying that value will also retrigger the accumulation rule, I believe in a way that will make it pointless. It seems I may be forced to use insert-unconditional! in some manner to solve this use case?

@UH13Y2FSA what do you mean that c & d “come later”? I think that is important to get a handle on.

What makes the timing of a & b differ from c & d? How are they batched and inserted in this way?

If you have different sources of facts, where a & b are just from a different “source” than c & d than you can reify some information onto those facts about their “source”. Then you can do eg.

(acc/all) :from [Item (= ?source-id source-id)]

If this is instead insertions outside of the fire-rules loop, you could have those outside insertions have some incrementing “session ID” or something that models “different points in insertion time”

I think you still do intermediate facts and use a rule to explicitly match the “latest” facts either via their “source” props or their “session ID” type of props.

What’s happening is that I’m batching a fetch of the facts for performance reasons… So that I can get the data multi-threaded. Further rules can fire that trigger another batch, but I don’t want to refetch what has already been fetched, so I effectively need to skip them.

I did work out a mechanism sort of what you had proposed with paging, but holding the current source-id in a fact that is incremented (atom) after the current items have been processed… Subsequent Item creations use the new number.

Are you calling fire-rules multiple times in this flow you have?

No, I for some reason didn’t want to go that route if I didn’t need to.

I’d be a bit worried about side-effects like atom updates with in a fire-rules loop. The reason is there is the truth maintenance system (TMS). It may arbitrarily fire RHS of rules and then retract them later when the LHS becomes no longer satisfied. If you perform side-effects that are not visible to the TMS, those cannot be undone. There’s a chance that what you have is still reliable. However, it is something to be leery of.

I’d prefer any sort of incremented mutable like this be done between successive fire-rules calls. So the TMS can operate in a “pure” env.

I see. The problem I was running up against is that (acc/all) doesn’t get invoked when more matching facts come in. Which feels like a bug to me.

If that had worked, then I wouldn’t have resorted to the mutation, but I’ll consider a fire-rules loop

It does via TMS. However, it could be something to do with your side-effects as I mentioned.

I’ll put together a simple example of what I tried, which wasn’t mutating.

I’d tend to think of rules as a good way to model a tricky flow of logic. However, I’d delegate side-effects to the external caller. They can call fire-rules multiple times as some external “state” has changed.

So I may have a fact that represents “already fetched” facts. And use that to exclude those from any new fetch. Each fire-rules loop, I’d query out what to fetch, fetch them, and add them to an “already fetched” fact to apply to the next insert/`fire-rules` loop.

An example of the outline of this idea is here https://gist.github.com/mrrodriguez/baaa6bf73e8a3b412970c648e208c293

Is using a fire-rules loop effectively any different than using insert-unconditionally? It seems like when you insert them before the fire-rules that amounts to the same thing as there is no truthiness in inserting those facts.

It can be similar. But you would rely on rule evaluation order with insert-unconditionally.

Those rules would need to go first and not interact with the TMS rules that may insert and retract multiple times seeking logical consistency.

So maybe not “first” but you’d need to be sure the unconditional rules aren’t meant to have any dependency on TMS managed rules.