Clojurians Log v2

I have pretty mixed feelings about removing the namespaces. The short answer is that they're namespaced on the backend (coming from a Datalevin DB), and then sent off to a CLJS frontend, where there is a lot of {:keys [a b c]} destructuring happening, which I can't do with namespaced keys. I have not yet decided if the tradeoff is worth it, though

{:alias/keys [a b c]} will destructure :alias/a, :alias/b, :alias/c -- do you have control over that cljs frontend? (you can also do {my-a :alias/a my-b :another/b...} if you need to destructure across multiple prefixes)

Oooo I did not know about {:alias/keys [a b c]} @seancorfield, thanks! That might solve the bulk of my problem. {my-a :alias/a my-b :another/b...} is what I was hoping to avoid

example for @seancorfield’s explanation,

(let [{:person/keys [name age]} {:person/name "Teodor"
                                 :person/age 99}]
  [name age])
;; => ["Teodor" 99]

You can also have multiple prefixes like that: {:person/keys [name age] :address/keys [street city zip]}

I'd use that, yes.

depending on the keys in that map you might want to add some sort of check? :foo/name and :bar/name would lose values and only end up with one :name. not a problem if the keywords from the same namespace.

You would also be converting any symbol keys to keywords. Whether that's an issue depends on your data!

In my case, all of the keys are keywords, so the symbols should be a non-issue @teodorlu. Good point @thheller about about overlapping names from different nses; I don't think that will ever come up in my data, but it's worth watching out for.

My question would be: why? If it's just to convert the map to JSON, for example, all the JSON libs either drop the qualifier by default or have a setting to control whether to do that.

My hunch would also be to keep namespaces as far in my system as I can! I love them, it gives data a solid foundation, and a means of tracing and finding usage through the code.