@devn: There isn’t any barrier to having non-Clojure types in a session. For fields, Clara will just fall back to using JavaBean properties if it can. https://github.com/rbrush/clara-rules/blob/0.11.1/src/main/clojure/clara/rules/compiler.clj#L165 You might get into trouble using things like Java primitives or maybe a falsey value, but I’d expect normal Java objects to work. As far as why, I work with @mikerod so I can speak to that; the short answer without saying too much is that while our group

group’s code is mostly in Clojure, we’re part of a larger Java system, and our external interaction points involve Avro records.

Oh, btw even though random Java objects are fine mutating them Java-style underneath the rules engine after inserting them isn’t, at least if you want predictable results 🙂

@wparker: ah, so the avro records you deal with are beans?

@devn correct. Not that facts have to be beans, it is just convenient for field access. You can always just use whatever functions/interop you want on the fact instead.

@wparker: i feel pretty daft asking, but again, im curious what an example of this looks like in clara's DSL

Are you talking about :fact-type-fn?

Either way, I'm curious to see (even a hackish, half-working) sample of this

We're talking about Avro a bit lately

i've been musing about rules existing at other layers of our platform, which may select an existing avro schema, or produce a new one, for instance

@wparker: also, regarding #157 -- i honestly don't recall when we made that change, only that we observed cache misses due to ordering concerns

It would just look like anything else, say

(defrule rule-using-bean [?fact <- AvroFact (meets-some-condition? field-on-AvroFact)] => whatever-RHS-you-want)

I suppose you could do interesting things with the fact-type-fn and Avro schemas, but that wasn’t what I was referring to

Say a fact-type-fn that used an Avro schema to determine the type.

But a generated Avro class can just be used like any other class

huh, i assumed there must be magic to make that work, but i must confess that my journey in programming has omitted serious java work, so while i understand chunks of the clojure compiler and such, i am often missing context w/r/t things like java beans

@wparker: thanks much for the explanation

Well, I haven’t personally created those Avro models, so I can’t exclude magic completely 🙂

But once you have classes, they are just that

You’re welcome

@wparker: also regarding 199 and your question about clojure equality, I don't think we've ever done anything with activation groups

Well, it wouldn’t have to be activation groups in particular, I was just choosing that as an example of one of the options to mk-session

Date: Wed Dec 30 16:46:15 2015 -0600

Caching is on rules + options, which makes sense since the options impact the session semantics

so, #157 was Jan 12

😄

err, but closed Feb 4

but, yeah, makes sense.

Now I'm curious to see if removing that call to (set) changes behavior

Do you mean trying with it removed on your code on the case that had a cache miss?

yes

@mikerod: http://dev.clojure.org/jira/browse/CLJ-1733

Was just walking through open clojure issues and wanted to drop it here since I saw you wrapping with #=