datomic 2022-08-17 | Slack Archive

seepel07:08:53

I'm curious, do folks find it more useful to create functions that perform queries or to create variables that hold queries. For example do you prefer

(defn find-by-email [db email]
  (d/q '[:find ?e
         :in $ ?email
         :where [?e :email ?email]]
       db
       email))

(def find-by-email '[:find ?e
                     :in $ ?email
                     :where [?e :email ?email]])

cjohansen07:08:28

The first, by far, since the query depends on the email parameter. Sticking the query in a var and then using it elsewhere will make the dependency on the var less obvious.

👍 3

Linus Ericsson14:08:12

If you are to use the query in var format, consider to use the map format - its mich easier to do introspection. I have used that map to add extra parameters (sorting etc)

steveb8n02:08:12

fn for me too. allows validation of args

seepel04:08:06

Thanks for the feedback! Makes sense to me. If anyone has a counter argument I’d still love to hear it!

steveb8n06:08:45

I’ve got one for you. I frequently compose queries using pull expressions. those pull expressions can be def’d since they don’t have any dependencies

seepel08:08:17

Ah interesting, I could see that being useful. By pull expressions do you mean something like this?

(def everything '[*])

(d/q '[:find (pull ?u pattern)
        :in $ pattern
        :where [?u :user/email _]]
      db
      everything)

steveb8n08:08:12

yes that’s one way to do it. I tend to use app-template to merge them in

steveb8n08:08:22

I try to use :in values for :where clauses only but that’s just a personal preference

seepel08:08:47

What is app-template?

steveb8n08:08:03

https://clojuredocs.org/clojure.template/apply-template sorry it’s Fri-eve here, I should not drink and slack

seepel09:08:50

Awesome, thanks so much! 🍻 Cheers, for what it's worth I'm glad you diid!

tony.kay23:08:23

I’ve noticed that the official API docs (https://docs.datomic.com/client-api/datomic.client.api.html#var-db) on d/db say that there is ILookup access to a key named :db-name. That is nil for me in Cloud and dev (memory) databases. I see a :database-id in production databases, and an :id in memory ones. Not sure where the best place to report that is, so I’m saying it here in hopes someone on the core team will pick it up. I’m doing caching of things based on which database something comes from, so having a key I can safely derive from the db that isn’t the db itself is important and useful. For now I’ve been using the :database-id, but that worries me since it is an undocumented key.

👍 1

2022-08-17

Channels