[EDIT] clara-tools pulls in old version of clara-rules (was: Query after insertion returns empty in minimal project)

[davidrupp]

When my project dependencies include only com.cerner/clara-rules (@0.15.0, currently), when I create a session and insert a fact, querying the session does not return that fact. If I add org.toomuchcode/clara-tools (@0.1.1) to my project's dependencies, the query works with no other changes. See https://github.com/davidrupp/clara-wtf for for a minimal recreation.

[alex-dixon]

Try adding (fire-rules) after the insert. I think rules have to be fired before rules or queries will do anything.

[mrrodriguez]

@alex-dixon is correct. There are actually quite a bit of interesting optimizations that can be made in the engine if the state of the working memory is "undefined" until after fire-rules has been called.
Among these, #268 was done.
I think it is best to think of insert, insert-all, & retract as "lazy" operations on the working memory state. However, to cause them to be "realized" you have to fire-rules.

In short, there are times when it is significantly cheaper to process changes to working memory in batch rather than one-at-a-time.

They do not automatically get "realized" via running a query. Although, I think the argument could be made that perhaps query could force the realization - which would mean to have query to force a fire-rules if hadn't already been done. This may help avoid confusion.

Side note: Drools is a really popular rules engine on the JVM (Java-centric) and it also exhibits a similar behavior in that the operations on working memory are done "lazily" and you have to call fire rules to have the engine fully realize all the changes.

So Clara isn't the first rules engine out there to have this behavior.

[davidrupp]

Yes, (fire-rules) was one way I found that I could read my own writes. I just found it curious that simply including clara-tools in my project.clj dependencies -- with no other changes -- caused these non-lazy inserts. I also like the idea of being able to initialize my session with some baseline facts without necessarily having to trigger any rules because of them.

[davidrupp]

Put a different way, if inserts are expected to be lazy, including clara-tools as a dependency causes that expectation to be violated.

[davidrupp]

This makes the clara-examples project a potential source of confusion for folks trying to learn stuff. I witnessed the lazy behavior in my own project, and the non-lazy behavior in clara-examples, which made me wonder if I was doing something wrong.

[davidrupp]

A couple of observations:

• clara-tools @ 0.1.1 declares a dependency on [org.toomuchcode/clara-rules "0.9.0"]
• clara-rules @ 0.9.0 has an implementation of (insert) that does (l/insert-facts! transient-listener facts); modern versions implement the lazy behavior as discussed at Reduce transitions between transient and persistent memory and facilitate performance enhancements to fire-rules #268

So I think what I'm seeing in the clara-examples projects is, when clara-tools is in my dependencies, I have a transitive dependency on clara-rules @ 0.9.0 which is "winning" the classloader race, no matter what my declared version is in project.clj. Anyone care to corroborate?

[mrrodriguez]

Ok, so what seems to be going on here is just due to some not-well-maintained experimental dependencies giving you dep conflicts.

• clara-tools is still in an experimental state
• clara-example looks to be lagging behind in the version it is using of this experimental clara-tools

You could try to get some sane behavior by combining the newer versions of each of these explicitly until some of these issues were fixed:

[com.cerner/clara-examples "0.2.0-SNAPSHOT" :exclusions [[org.toomuchcode/clara-tools]]
[org.toomuchcode/clara-tools "0.2.0-SNAPSHOT"]
[com.cerner/clara-rules "0.15.0"]

That is one way to approach it, but I think you'd have to build clara-tools yourself for this modern version that doesn't have this issue. Alternatively you could try to just be sure the old version of clara-rules was excluded.

[com.cerner/clara-examples "0.2.0-SNAPSHOT" :exclusions [[org.toomuchcode/clara-tools]]
[org.toomuchcode/clara-tools "0.1.1"  :exclusions [[org.toomuchcode/clara-rules]]
[com.cerner/clara-rules "0.15.0"]

It isn't guaranteed that any mix-match of old and new dependencies would still work like this since they haven't been building or testing together like that. Also, 0.9.0 clara-rules is a bit old now and there may have been breaking changes.

All of this is really just a stop-gap. The versions should probably all be put in sync again and the proper artifacts released.

[davidrupp]

I'll probably just leave clara-tools out for now, myself, and deal with modern insert behavior. I have no idea what it would take for clara-tools to not introduce a transient (possibly circular) dependency on a specific version of clara-rules; I'll let you all sort that out. The biggest concern I would have as a maintainer on this project is that adding this seemingly innocuous dependency -- as implicitly endorsed by clara-examples -- can silently break things in weird and exotic ways.

[alex-dixon]

@davidrupp Sorry you had to deal with this. I started out using clara-tools as well and discovrered most of its features (or at least the ones I wanted to use) are included in clara proper now.

[WilliamParker]

My inclination would be to add an explicit exclusion of clara-rules from the clara-tools dependency for now and add a comment explaining why assuming that it doesn't break anything in clara-examples.

Is there particular functionality that you/others are using in clara-tools that isn't part of the larger web app there? If so perhaps it would make sense to factor that out into Clara, another project, or some such.

[rbrush]

We probably should consider clara-tools itself as deprecated and remove usage of it from clara-examples. The core clara-rules project has pretty good inspection functions now, and clara-tools hasn't been maintained in some time.

There are some cool GUI-related things in clara-tools that might be useful in another home if there is interest in maintaining that.

[WilliamParker]

I've created a PR to remove the clara-tools example: oracle-samples/clara-examples#14

[WilliamParker]

I've logged rbrush/clara-tools#12 to track on what sort of notice we want to add to clara-tools.

At this point I think this issue can be closed, noting that clara-tools has been removed from clara-examples. Any objections?

[davidrupp]

None from me. Thanks.

…

Sent from my iPhone

On Jul 26, 2017, at 7:04 PM, William Parker ***@***.***> wrote: I've logged rbrush/clara-tools#12 to track on what sort of notice we want to add to clara-tools. At this point I think this issue can be closed, noting that clara-tools has been removed from clara-examples. Any objections? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[WilliamParker]

Closing.