Fork me on GitHub
#datomic
<
2023-03-08
>
cch114:03:40

I’ve just updated my cloud installations to the latest version, 990-9202, as well as all my app dependencies as https://docs.datomic.com/cloud/releases.html#current. Strangely, when I try a push operation I see dependency conflicts despite using the latest versions. Any thoughts?

cch114:03:59

Here are the reported conflicts:

:dependency-conflicts
 {:deps
  #:com.datomic{client-api #:mvn{:version "1.0.58"},
                client #:mvn{:version "1.0.126"},
                client-impl-shared #:mvn{:version "1.0.98"},
                client-cloud #:mvn{:version "1.0.120"}},

jaret15:03:30

@cch1 You can generally ignore the dependency conflict map. I would ensure that you do keep your ion-dev, client-cloud, etc deps updated to match the releases page. The problem with the conflict map is our current approach requires that dev build cloud locally to get an updated deps list into a file and then push another build. We are not currently doing that for every release for many reasons. We are in the process of investigating using another approach for dependency conflict checking to make this map more useful to users, but right now it is simply checking the version against a version that was used to produce cloud and is potentially incorrect.

cch116:03:46

That is worrisome, especially the “generally” part! Can you provide any more guidance on which conflicts I can ignore and which ones I can’t?

jaret17:03:43

@cch1 you’re absolutely right. You and customers using ions should report every deps conflict you cannot explain and we on the Datomic team should provide an explanation or investigate to determine if the conflict actually represents a problem. In this case, the deps you are having a conflict with are conflicts because after we shipped <tel:990-9202|990-9202> to AWS marketplace we realized that we missed a step to publish client-cloud to maven. Thus we released 1.0.123 and the other deps in your map which it depends on. The version of Cloud however is unaware of this list until we ship the next release so the dependency conflicts are shown. I will again say that this kind of problem is why we need to provide better dependency conflict checking in cloud. There is a gap between what we typically need to get to marketplace and what we release in the interim. It’s a feature we are working on so these maps can be better relied upon.

2
cch118:03:35

Thanks, @U1QJACBUM. I’m going to note then that the four conflicts noted above are “OK” and if others pop up before the Datomic team gets a new version out that addresses the issue, I’ll run them past you at that time.

Dimitar Uzunov15:03:41

How do I get io-stats from pull and pull-many? I don’t see it documented here: https://docs.datomic.com/on-prem/clojure/index.html

Keith15:03:06

You must pass a map to pull like:

(d/pull db {:selector '[:attr/foo] :eid 123 :io-context :your/io-context})
:eid can be a lookup-ref instead of an actual eid

gratitude 2
Dimitar Uzunov15:03:24

Thanks! I will try it out!

Dimitar Uzunov14:03:15

(d/pull db '[:attr/foo] 123 :io-context :your/io-context)

Dimitar Uzunov14:03:19

seems to work for me

Dimitar Uzunov14:03:09

I didn’t know d/pull can accept keyword arguments like :selector, its not in the api docs as far as I can tell

Keith14:03:08

Ah I see now - only the client API accepts a map arg: https://docs.datomic.com/client-api/datomic.client.api.html#var-pull Glad it works though!

jaret15:03:30

@cch1 You can generally ignore the dependency conflict map. I would ensure that you do keep your ion-dev, client-cloud, etc deps updated to match the releases page. The problem with the conflict map is our current approach requires that dev build cloud locally to get an updated deps list into a file and then push another build. We are not currently doing that for every release for many reasons. We are in the process of investigating using another approach for dependency conflict checking to make this map more useful to users, but right now it is simply checking the version against a version that was used to produce cloud and is potentially incorrect.

jaret17:03:43

@cch1 you’re absolutely right. You and customers using ions should report every deps conflict you cannot explain and we on the Datomic team should provide an explanation or investigate to determine if the conflict actually represents a problem. In this case, the deps you are having a conflict with are conflicts because after we shipped <tel:990-9202|990-9202> to AWS marketplace we realized that we missed a step to publish client-cloud to maven. Thus we released 1.0.123 and the other deps in your map which it depends on. The version of Cloud however is unaware of this list until we ship the next release so the dependency conflicts are shown. I will again say that this kind of problem is why we need to provide better dependency conflict checking in cloud. There is a gap between what we typically need to get to marketplace and what we release in the interim. It’s a feature we are working on so these maps can be better relied upon.

2