Fork me on GitHub
#clara
<
2018-02-02
>
mjmeintjes21:02:52

What's the best way to ensure that a fact doesn't get inserted twice. Is there a way to ensure that duplicate facts don't get inserted into the same session?

mikerod21:02:29

@mjmeintjes I talked about this in a few posts above if you can see them?

mikerod21:02:52

I discussed “cardinality” of equal facts in clara and ways to work with it

mikerod21:02:56

and tradeoffs etc

mjmeintjes21:02:39

Thanks for the information. I was thinking more about how to efficiently update the session - for example, I have a list of rows from the database. Before firing the rules I need to make sure that all the db rows are included in the session. However, I do not want all the rules to be inserted each time (which causes lots of duplicates), and I also don't want the session to be recreated each time. What I've done now is create a query to retrieve the already inserted rules from the session, and then I'm comparing that against the db rows, and then I only insert the new ones. I was just wondering whether that is the best solution.

mikerod21:02:58

@mjmeintjes I think that is a fine way to do it. I think there may be a potential enhancement to clara to do something like an “update” of facts and/or a “mode” that had the working memory act in a set-based way there weren’t duplicates. For now though, the external query idea is good if it can work for you

mjmeintjes21:02:28

Yeah, being able to efficiently update the session would be great, as each time I've used Clara that's something that I've run up against. The only problem with the query approach is that queries are only updated once fire-rules has run, which means you can still get duplicates if you aren't careful to run fire-rules before inserting any new data.

mikerod21:02:26

@mjmeintjes Yeah, you should never query prior to fire-rules. I’d call that an “undefined” state

mikerod21:02:55

Clara does some “lazy” sort of batching that isn’t forced until fire-rules. It can do some good optimizations with this and could even get more “lazy” in the future I’d think.

mikerod21:02:31

I think it can be difficult to do “logical updates” to facts with what Clara currently offers

mikerod21:02:26

it relies basically entirely on the caller to query facts and figure out what inserts/retracts to make externally. That is if the rules are going to be written in a way that can smoothly work with the truth maintenance system and logical inserts (ie not insert-unconditional! and right-hand-side based retract!).

mikerod21:02:36

These sort of discussions have came up quite a bit here lately.

mikerod21:02:09

I wrote this a while back http://www.metasimple.org/2017/12/23/clara-updating-facts.html Not sure if it is really useful to you. You seem to already have a setup you’ve been using to do your de-duping anyways

mjmeintjes21:02:00

Thanks for that post, I'll have a read. Love reading information about Clara, as it is such a great programming model. Always trying to find places to use it.

mikerod21:02:23

Well that’s good.

mikerod21:02:53

Yeah, I’d like to try out some ideas to deal with these sorts of things. I think some sort of rule-triggered “update” would be interesting.

mikerod21:02:05

As well as externally specified updates

mikerod21:02:36

The challenge would be to do so in a way that interacted in a well-defined way with the truth maintenance system and logically inserted/retracted facts.

mjmeintjes22:02:56

Thanks, useful post, helped clarify/validate the approach I'm taking.