Clojurians Log v2

Yesterday I started experimenting with Malli for that, and I was thinking I might completely get rid of the builder-fn (just returning unqualified keywords all the time from SQL and letting Malli do the qualifiying)

Here is my new approach: https://clojurians.slack.com/archives/CLDK6MFMK/p1726161486563099

Not directly answering your question, and some adjacent thoughts: https://vvvvalvalval.github.io/posts/clojure-key-namespacing-convention-considered-harmful.html needs to be in the conversation. I disagree. We do :org.namespace/name <-> "org_namespace__name" two-way conversion (note double __). It works well us.

> We do :org.namespace/name <-> "org_namespace__name" two-way conversion (note double __). It works well us. this is fine if you don't mind coupling your database schema with Clojure, we used to do that in a previous company I worked at. however this does not solve the case of json aggregates for instance?

Hence, not answering your question directly 😊

I do : :com.example/name I’m still lost with namespacing. I prefer it but I do often wonder. Over the years I’ve pretty much gone all-in with clojure naming conventions, and opting for tooling like datomic to avoid mapping data

If I had to solve a problem like yours, I think I would take the boring approach and hardcode all the mapping with pathom aliases or something. As apposed to the dynamic way, introspecting the db and converting with the kebab-case-transform or whatever. Although this works just as good. Although tedious up-front, if https://docs.datomic.com/reference/best.html#grow-schema I’m probably in good shape. And also couldn’t be simpler to grok

I’d probably struggle with modelling data though (eavt vs tables)

aliases would not work for remapping, if your db return :name you'd have many aliases from :name to the actual qualified keyword

also I am specifically taking a different approach because pathom performance is too bad for some queries (not to mention it gets so much slower as the number of resolvers increase, and I have many many many resolvers)

Pathom is particulary bad at returning big collections, if you return 1000 items, you automatically get +1 sec queries just because it takes at least 1ms to check each items, more if you add subqueries for each items (regardless of batching or not)

The only workaround I could find is to declare the resolver final, but then you have to do everything by yourself (mapping and validating)

> also I am specifically taking a different approach because pathom performance is too bad for some queries (not to mention it gets so much slower as the number of resolvers increase, and I have many many many resolvers) Yeah this is deal breaker every now and then for me too. For some things it isn’t an issue, and for others it is. I avoid sending large collections through pathom whenever I can. For filtering and aggregating I lean on the db for it

For filtering and aggregating I lean on the db for itsame and then I need to re-map for pathom, which is tedious for nested data, and so far this solution with malli seems to be the best cost-benefit afaict

However, when I am modelling stuff with collections, I’m very conscious about the amount of data i’m handling. Most of the time my collections just have ids. {:io.example/id …} , Most filtering and aggregating I get done on the db. But If i need to do some logic in pathom (filtering on: :io.example/active? or something) then I only grab that data. Then I have seperate resolvers that batch fetch any remaining attributes requested in the query

Not every problem can afford the various pitfalls, occasionally I’ll have handle things differently