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)
well this is exactly what i was looking for. thank you @lanejo01!
NP, I just wish I would have thought of it sooner 😂 . Definitely could have used this over the years.
The d/client API docs have the following statement:
> Create a client for a Datomic system. This function does not communicate with a server and returns immediately.
However, running a call to d/client
seems to indicate this function does communicate with a server in some regard.
(d/client {:server-type :ion
:system "my-system"
:endpoint "<http://i-dont-exist.datomic.net:8182>"
:region "us-west-2"})
Execution error (ExceptionInfo) at datomic.client.impl.cloud/get-s3-auth-path (cloud.clj:179).
Unable to connect to <http://i-dont-exist.datomic.net:8182>
Given that, should the d/client
docstring be updated to mention it does do some server communication?Also, should that function expose a :timeout
option?