If everything is in the same process and doesn't require any Redis-specific functionality, then you should be able to use a plain queue or a map.

datascript ?

https://github.com/Factual/clj-leveldb

I was hoping for some level of persistence, datascript does not feel like a great fit as I am not storing db like data just temporary expiring data

Haven't tried it yet, but maybe this one: https://github.com/juji-io/datalevin

(more features than you need, but still)

do you need a separate process to store on memory?

https://github.com/tonsky/datascript/blob/master/docs/storage.md Datascript added support for storage in a recent release.

datascript / datalog does not really feel appropriate, I already have xtdb but I want to store temporary data hashmap style with a little bit of persistence, leveldb may be an option just trying to figure out if you need a server like redis

Just a plain kv store can be covered by many, many products. It doesn't even have to be Clojure-related if you throw in EDN or Transit to (de)serialize the data.

If you need just key value store and nothing else, I think the standard choice is rocksDB, which does not require a server. Or Sqlite and just add a key-value table.

that's what I am basically after a key value store with persisteance with out an extra software like redis, ie via a library

you don't need to use datalog to use datascript as a simple k/v store. https://tonsky.me/blog/datascript-2/ almost never uses the query interface: > "...in 3 years of full-time web app development with DataScript I haven’t used a single query. ...I find it faster to use direct index access for simple stuff."

oh rocks that could be an option I have that for xtdb already

rocks is leveldb fork

It's not something I know much about rocks now to find a clojure library for it 🙂

If you want to avoid additional external dependencies (which would be my recommendation unless you're absolutely sure your use case requires them because of the complexity they are likely to add), and you don't need to worry about synchronizing or sharing state (which it sounds like you don't), there are also very simple libraries like https://github.com/jimpil/duratom which let you persist the state of a Clojure atom to disk.

I think I will use rocks as I have that as a local store for xtdb so I already have a dependency for that, duratom sounds exactly like the sort of thing I was looking for so worth keeping in mind for other projects

Datomic Local is quite nice https://docs.datomic.com/cloud/datomic-local.html

Actually i went with duratom in the end, it lets you choose the store so I can start with a file based store and switch to redis later on nice little library as it works the same as an atom, only missing expiring keys but I created a little wrapper for that so thanks for that suggestion @UFTRLDZEW

I don't use that config myself, but it feels like an incompatibility between some dependencies. Maybe something overrides the dependency on httpkit that Portal has with some old version?

server/as-channel comes from [org.httpkit.server :as server] My suspicion is that you are getting an older version of http kit

it wants http-kit/http-kit {:mvn/version "2.7.0"}. Do you know how to find out what version you are getting? And can you post your full deps.edn file here?

of course

{:paths [:clj-paths :resource-paths]
 :aliases {:clj-paths ["src"]
           :resource-paths ["resources"]
           :dev {:extra-deps {org.clojure/tools.deps {:mvn/version "0.18.1374"}}}}
 :deps {org.clojure/clojure {:mvn/version "1.10.1"}
        hiccup/hiccup {:mvn/version "1.0.5"}
        http-kit/http-kit {:mvn/version "2.3.0"}
        metosin/reitit {:mvn/version "0.3.9"}
        ring/ring-defaults {:mvn/version "0.3.2"}
        com.stuartsierra/component {:mvn/version "1.1.0"}
        aero/aero {:mvn/version "1.1.6"}
        yogthos/config {:mvn/version "1.1.4"}}}

yeah

you specify version 2.3.0 which is too old

looks like it

change that to 2.7.0

that didn’t error before installing praticalli

but that’s maybe because I’ve deleted the .clojure which had a cache folder maybe

thanks

worked like a charm

Macros are run before aot compilation, so when you load aot compiled code macros have already been expanded away

Yes. That's why the work is being done at macro expansion time, so it doesn't need to happen later. But when I'm messing about at the repl, I want to re-run the work when I execute the generated function, so I was looking for a (was-aotd?) type thing to re-run the work, cos it depends on some files that I might have changed on my machine for testing.

It's not a massive deal - I can just re-eval the definition, and it re-expands the macro - I just sometimes forget, and I was wondering how hard it would be to work around.

I guess I could see if something nrepl looking was on the classpath ... but that seems even more hacky 😉

Or I could set an env var during the aot process, and capture that value? if it's not there re-do the work ... but I feel like i'd rather not change the ci process just cos I forgot to eval something a few times ...

I just feel like I've not had the good idea yet ...

very hesitant to suggest this, since I am not wild about the idea of distinguishing between aot compilation and not, but

(def aot (atom true))

(defmacro f []
  (reset! aot false)
  nil)

(f)

(defn aot? []
  @aot)

That smells brittle

@U0NCTKEV8 thanks - I'll try that and see how it breaks 😉