Nevermind, answered my own question:

(let [{truek :true} {:true 10}]
  truek)

yup… its easy to overlook that {:keys [foo bar baz …]} is syntax sugar over the original map destructuring syntax

the trouble is that true isn't a symbol, which means that you cannot bind something to that name

You can construct a symbol with the name true but it cannot be read as a symbol

the registry exists as aliases in the current Namespace object already and you can see those via ns-aliases . the bigger problem is that the printer doesn't print keywords with those aliases

this data comes from an XML file, so there are no NS aliases for it, that's why i mentioned that i'd be happy to maintain a mapping myself, just want a printer which can understand such a mapping 🙂

I see, have you tried parsing with :namespace-aware set to false? not sure if that would give you something easier to work with

i haven't tried that flag, because i've assuemed it would just drop the NS, but i DO need the NS, so i can roundtrip the XML data

if it's for dev workflow you can adapt this:

(comment
  (defmethod print-method clojure.lang.Keyword [o ^java.io.Writer w]
    (if-let [k-ns (namespace o)]
      (if-let [k-ns-alias (some (fn [[alias the-ns]]
                                  (let [ns-str (str the-ns)]
                                    (when (= ns-str k-ns) alias)))
                                (ns-aliases *ns*))]
        (.write w (str "::" k-ns-alias "/" (name o)))
        (.write w (str o)))
      (.write w (str o)))))

but note that this affects the printing of keywords everywhere

might still be a good stop-gap solution, just need to have a way to reverse its effect

eval (defmethod print-method clojure.lang.Keyword [o ^java.io.Writer w] (.write w (str o))) 😅

you could also add a conditionnal on a dynamic var in the method body

CacheProtocol is intended for immutable caches, so implementing it on top of mongodb, now you have 2 problems: your immutable thing is mutable, and you're using mongodb

In most cases the caches are put into an atom to make them useful. And my question would remain the same if the storage backend was postgresql.

Same problem, CacheProtocol is for immutable caches

If you put a mutable implementation of CacheProtocol in an atom, it won't work correctly because swap! can run what you pass in more than once

Wrapping an atom around immutable things and implementing an API for immutable things directly on a mutable thing is not the same thing at all

The immutability looks tangential to my question. Caches return a "new" updated cache. That we store it in an atom or a DB is an implementation detail. swap! can retry the functions, which is why they must be free of side-effects. But it's not a property of the caches. Also, from the docs: "Caches are generally immutable and should be used in conjunction with Clojure's state management, such as atom. SoftCache is the exception here, built on top of mutable Java collections, but it can be treated as an immutable cache as well."

So to come back to my question, it looks like many of the implementations in core.cache cannot be serialized, which is why, as far as I can tell, they can't be used with durable backends.

> Wrapping an atom around immutable things and implementing an API for immutable things directly on a mutable thing is not the same thing at all Okay, thinking more about it I see the difference now. A mutable cache could change under the other cache layers and screw things up...?

Perhaps the refresh has zapped the ns that tenant was aliased to and the context for ::tenant/enable-recalls? is no longer valid somehow. (I was just saying in another thread that I have always avoided the reload/refresh stuff because of edge case failures like this)

the difference in errors is one the invalid token error is from the clojure reader, the invalid keyword error is from tools.reader

so something is trying to read something that contains the keyword using tools.reader, in a context where *ns* is not bound to a namespace where the appropriate namespace exists

thanks @U04V70XH6 i'll ponder that a minute after i fix this. thanks @U0NCTKEV8 that makes sense, I'll just have to find where the keyword is read where the ns isn't bound.

it isn't that *ns* isn't bound, it is that it is bound to a namespace where the alias doesn't exist

Right, i suffer from not being sure how much exposition is worth giving To clarify and confirm by example, the idea is that this would work: (ns foo (:require [centriq-web.tenant :as tenant])) ::tenant/enable-recalls? This would not: (ns foo) ::tenant/enable-recalls? ... (i hope that's right) The interesting bit in this case is that that it's happening via tools refresh, which i don't use nearly as much. (maybe, as sean suggests, that's ideal) But i'm not sure how to get away with the workflow i want (update a server endpoint so i can use it to get changes on my client) without going this route.

you need to figure out what is calling tools.reader

ah, of course tools.namespace uses tools.reader, so could be that

do you have any random .clj files on the classpath that just contain like a map or something, and don't actually start with a ns form?

Is it failing because the keyword is being qualified twice? Once explicitly with tenant and implicitly with the current namespace via :: :tenant/enable-recalls? I assume is the correct form Or have I missed something?

:: allows you to resolve keywords via aliases that the current value of *ns* has

It ended up being because of a file called centriq-web.graphl_scratch that had this:

(in-ns 'centriq-web.graphql-service)
(require '[centriq-web.tenant :as tenant])
...
::tenant/enable-recalls?