Fork me on GitHub
#clara
<
2020-06-29
>
matthew.pettis14:06:13

Is there a way to just dump or inspect all of the facts that exist in a session? I am thinking about looking at taking a session (which has to be defined with a static set of rules, if I understand correctly), dumping the facts, and creating a new session with a different set of rules to apply to the facts from the previous session.

matthew.pettis15:06:05

Also, I've seen in youtube talks some (at the time, just alpha-level) tools that will diagram out a set of rules or fact-firings on the given state of the working memory. Does anyone have any links to tools like this to play with?

mbragg18:06:57

@matthew.pettis You can inspect a session to return a number of different rule/fact data structures http://www.clara-rules.org/apidocs/0.9.0/clojure/clara.tools.inspect.html

mbragg18:06:31

That should enable you to retrieve all the facts inserted

mbragg18:06:01

https://github.com/rbrush/clara-tools might of been what you saw in that YouTube talk

mikerod19:06:44

@matthew.pettis in general I’d say it’s best to make targeted queries that you use to extract the facts you want to use in the next set of rules.

mikerod19:06:18

That’s your smoothest path forward.

mikerod19:06:00

There are some inspect namespaces and stuff in clara you can look at too. But typically more for inspection at a different sort of level

mikerod19:06:13

I’m just on mobile so can’t pull up much currently

mikerod19:06:21

Clara-tools maybe relevant. I think the codebase is likely outdated though. But perhaps gives extra insight. Clara has inspection and tracing things built in to an extent too. And then there is a listener api you can hook into if you require more specific things.

matthew.pettis19:06:00

Thanks @mbragg and @mikerod -- I'll take a look at these things.

wparker21:06:30

Agreed that if you need to pull out facts, targeted queries are probably the way to go. You could write a query that would match all facts e.g. against Object on the JVM, but the performance impact of that could be significant. You might consider whether you actually need multiple sessions though - what is the motivation there as opposed to having the facts you’re extracting trigger those rules in the same session? You could use a design pattern where you have subsets of your system that have “private” facts that by convention are only used in say a particular namespace, and “glue” facts that connect different parts. It is highly domain-dependent but that’s a pattern I’ve used before. @matthew.pettis