Fork me on GitHub
#clara
<
2016-06-11
>
wparker00:06:40

@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

wparker00:06:37

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

wparker00:06:43

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 🙂

devn00:06:43

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

wparker02:06:12

@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.

devn02:06:53

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

devn02:06:17

Are you talking about :fact-type-fn?

devn02:06:52

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

devn02:06:08

We're talking about Avro a bit lately

devn02:06:30

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

devn02:06:03

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

wparker02:06:47

It would just look like anything else, say

wparker02:06:15

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

wparker02:06:53

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

wparker02:06:27

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

wparker02:06:50

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

devn02:06:58

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

devn02:06:28

@wparker: thanks much for the explanation

wparker02:06:39

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

wparker02:06:48

But once you have classes, they are just that

wparker02:06:55

You’re welcome

devn02:06:20

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

wparker02:06:31

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

devn02:06:02

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

wparker02:06:15

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

devn02:06:08

so, #157 was Jan 12

devn02:06:23

err, but closed Feb 4

devn02:06:33

but, yeah, makes sense.

devn02:06:17

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

wparker02:06:43

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

devn21:06:30

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