Use clojure to construct the query as data

(defn query-players
  [db rules player-name wants-is-player-rule?]
  (->
   (cond->
       '{:find  [?player]
         :in    [$ % ?player-name]
         :where [[?player :player/name ?player-name]]}
     wants-is-player-rule? (update :where conj '(?is-player ?player)))
   (d/q db rules player-name)))

(query-players (d/db conn) the-rules "player1" true)

No, it’s an address, addresses can change.

Oh interesting. When does it change at the moment? What’s the migration strategy to go from one format to another?

At the moment it doesn't, but you asked if you can rely on the endpoint address "ALWAYS" following that format.

I see. If it were to change, how could that be done safely?

It’s just a different string. What if the endpoint had a uuid in it? I’m not sure what you mean by “safely”.

If it were to change, client applications would need to know about which endpoint to point to. By safely I mean informing the client application which endpoint it should use before and after the switch.

“Client applications” meaning not ions?

Correct

How do they know what endpoint to hit right now?

Statically defined string at startup. Seems like a switch of that endpoint would be require application downtime.

Doubtful. That statement is only true because you aren’t using a mechanism to dynamically update that endpoint and the datomic client using it.

Imagine switching the query groups your client applications point to with zero downtime. How would you do it?

Oh I see. You’re saying in the event Datomic changes it’s endpoint, we’d need to do an A B switchover by deploying an entirely new query group?

That in combination with either deploying a separate set of client applications pointed at the new QG or having your client applications being able to reset their clients and connections by polling for config values at a low rate (15 mins)