I question whether this is better, but it is DRY:

(defn people [db person-pull person-ids]
  (d/q '[:find (pull ?e person-pull)
         :in $ person-pull ?ids
         :where
         (or-join [?e ?ids]
                  (and [(= ?ids *)]
                       [?e :person/id])
                  (and [(!= ?ids *)]
                       [(identity ?ids) [?id ...]]
                       [?e :person/id ?id]))]
       db
       person-pull
       person-ids))

use the special id value * to mean “everyone”

otherwise it’s a vector of entity identifiers

Hmm does not seem worth the hassle. I was thinking of using the map form and manually inject the parameter @U09R86PA4 …what do you think?

there may be a penalty from not caching the query plan, since each query is a new instance. But I’m not sure if cache lookup is by identity or by value

Got it. good point. Seems like a case where duplication is cheaper than the wrong abstraction 🙂

pull (and most things) can take any entity identifier, which includes entity ids, idents, and lookup refs. In your case, (d/pull db [:person/id :person/name :person/surname] [:person/id "the-id"]) would work

Ah interesting, that I didn't know. Thanks!

someone else can correct me if i'm wrong, but i use cast/event for all sorts of things including application level logging

@U4N27TADS to echo what Josh is saying it's for ordinary occurrences of interest to the operator. Whereas an Alert is for an extraordinary occurrence that requires operator intervention. These are conventions you can choose to follow or not in your use of the ion.cast.

Hello @U0GC1C09L, @U1QJACBUM! Thank you for explanation. In the end we decided to go with event bridge or sns topic directly. It is problematic to route events from cloudwatch logs to aws lambda functions. As the only option there is subscription filter (max 2 per log group). Maybe I missing something, but haven't found solution where I am able to get events submitted using cast/event to lambda functions.

i don't know if this is useful to you, but we cast/alert exceptions to CloudWatch, and then use a CLJS Lambda to send them to Slack to torture our developers. cast/events are not really any different, except for maybe the frequency at which they appear, but i think log streams are batched. (sorry for the lack of a proper README, it was a hobby project) https://github.com/joshkh/datomic-alerts-to-slack > It is problematic to route events from cloudwatch logs to aws lambda functions. As the only option there is subscription filter (max 2 per log group). for application level logs and alerts, we tend to the use a common message throughout the application (e.g. {:msg "<app-name>-application-log"} ) , and then we attach other keys such as :env and :query-group . this provides us different levels of filtering while keeping our logs all in one place

but if SNS works for you then go for it! 🙂 i just prefer CloudWatch because cast serialises Clojure to JSON very well, and being able to add arbitrary keys at any level is useful for filtering