Fork me on GitHub
Carsten Behring11:02:02

@mkvlr Which use-case do you have in mind for the "persistent cache" functionality ? From my experience it seems to be "very difficult" to guarantee that all forms get persistent successfully via nippy. -> (most ???) things will therfore be re-evaluated after JVM restart one-time (and then they are in the in-memory cache), as most forms depend on each other in some way.


anything that takes more than a few seconds to run. The ease or difficulty of this is largely context dependent I think. When you build up data structures or indices out of pure clojure data as is the case with most code we’re writing this works like a charm.

Carsten Behring16:02:05

Yes, I changed my "result type" of my model training to be "pure data" (without functions). And now the persistent caching works as expected.

Carsten Behring13:02:47

Yes, indeed, you are right. But "pure data" is then a kind of "key requirement" of the persistent caching. My current use case is "99% pure data" (with 2 functions deep inside the pure data) -> I will try as well to re-think my use case for ways to remove the 2 functions. I think it is important to have logging which explains "what failed to get cached".

Carsten Behring13:02:16

Can we have this as a top level function in Clerk ? Like "clear-in-memory-cache!" ?

(reset! webserver/!doc {})

Carsten Behring13:02:40

and maybe rename clear-cache to clear-persistent-cache ? So to communicate the 2 layers of caching and a clean way to clear both.


clear-cache! should just wipe the in memory cache as well I think

Carsten Behring14:02:30

Not sure, if we need to differenciate.

Carsten Behring14:02:59

Probably it should do both, just meaning "clear it all !"

👍 1
Carsten Behring18:02:07

I am a complete newby in Clojurescript. But if you tell me how to translate this:

$('#example').DataTable( {
    data: data
} );
into a "viewer", then I can maybe figure out the rest. And trying to adapt your example into other javascript libraries.