Fork me on GitHub
#keechma
<
2019-07-12
>
carkh15:07:31

@mihaelkonjevic When i do this, am i correct in assuming that on each app-db change, there are two blackboard reactions working? what i'm trying to do here is to have the blackboard computation (quick in this example, but might be heavier) only being performed once

carkh15:07:54

you mentioned caching earlier, but is this a sub only thing ?

mihaelkonjevic15:07:35

AFAIK it should use same reaction, that's on the reagent core

carkh15:07:49

ok thanks

carkh15:07:18

i'll read this again (has been years) ... mhh i have a time value in this database i can log it in the reaction and see the result

carkh15:07:08

nope runs twice ='(

carkh15:07:48

in that page you linked, they use def'ed vars so there is only one instance of each reaction, gonna have to make some cache to make it work the way i want

carkh15:07:14

or some registry

carkh15:07:28

the sad thing is that it's going to be duplicating part of your work on subs

carkh15:07:34

that does the trick ! I can't see a production app restarting the keechma app so many times that the memory loss gets in the way

carkh15:07:42

might be trouble for parametrized reactions though ...

mihaelkonjevic16:07:43

Hm, reactions are cached on the keechma level but using them directly is out of keechma's scope. I wonder if there's a simple way to optimize it

carkh16:07:41

i've been looking for an lru cache memoize, but that's only available clojure side

carkh16:07:10

not such a big deal, i can cache the result of heavy computation by sticking the result in the app-db

carkh16:07:47

and my dependent subscriptions would then check on that

carkh16:07:04

bit messy, but gets the job done