Clojurians Log v2

Question on this release: A) The cloud-client update has an updated dependency on com.cognitect/http-client to version 1.0.148 B) When updating http-client's version, it does not work with com.cognitect.aws/api version 0.8.686 and throws an error with SSM calls C) Updating com.cognitect.aws/api to version 0.8.824 works for the SSM calls now, but when doing a clojure -M:ion-dev '{:op :push}', a conflict is reported about the ion-runtime wanting 0.8.686 of com.cognitect.aws/api 1. Is it for sure coming from the ion library dependencies, or a different part of the ion runtime? (Side Question: Is there a way to view the dependencies of the ion runtime?) 2. Is it safe to ignore the conflict between the ion runtime and our projects deps.edn? 3. Is there an update to the ion library coming to address this dependency conflict?

@steven.proctor we're looking at this. I don’t have an answer for you yet, just wanted to ack the thread so you knew we were looking into it

Actually upon further inspection, I think you will need to downgrade to the previously released versions. This is a problem with our usage of aws API and we are overwriting your attempt to pin the dep back to one that works. I will have more details tomorrow, but we will have to do something here to accommodate users using aws api (either further bump our usage or change our usage so they don't conflict)

Thanks for the update!

Hey Jaret! 👋🏼 The rel notes have a 2025 date instead of 2026 for at least one item.

Yikes. Classic!

Thanks! Fixing the date and kicking off a doc build to update that.

CC: @nonrecursive

Howdy users of Datomic Cloud, we are going to release another version of Cloud that removes our usage of aws-api so we are not conflicting with users (like @steven.proctor --thanks for the report of this issue!) who may desire a newer or older version of aws-api. I am going to make a similar announcement on the forum thread. If you upgrade to this version and use aws-api in your ion application you can encounter issues/errors if your usage is not compliant with aws-api 0.8.686. What to do: If you have already upgraded, as long as you have not created a new database or utilized administer-system to modify the schema of your existing DB for the discontinue tuple feature, you can downgrade. If you have used administer-system or created a new DB you will be unable to downgrade and utilize those DBs and will need to modify your ion apps usage of aws-api or wait for the forthcoming next Cloud release.

It is not quite clear in the documenttation...

🎉 thanks!

Hi @steven.proctor datoms will only return datoms matching the components you provided (so you can think of it as a range). seek-datoms will return datoms from the point you specify by components until you either stop consuming them or hit the end of the index. It and its reverse counterpart rseek-datoms are more primitive APIs than datoms. Does that clear things up a little bit?

Yeah, that makes sense. I had an intuition but it was not quite clear, and wanted to made sure I understood. Thanks!

(-> (doto "datomic:"
      (d/create-database))
    (d/connect)
    (d/db)
    (d/with [{:db/ident       :attribute/meta
              :db/valueType   :db.type/string
              :db/cardinality :db.cardinality/one}])
    (:db-after)
    (d/with [[:db/add :db/ident :attribute/meta "something"]])
    (:db-after)
    (d/with [[:db/add :db/ident :attribute/meta "something else"]]))
Execution error (Exceptions$IllegalArgumentExceptionInfo) at datomic.error/arg (error.clj:79).
:db.error/datom-cannot-be-altered Boot datoms cannot be altered: [:db/ident :attribute/meta "something else" 13194139534314 true]

i thought maybe it's an unintentional consequence of protecting built-in attributes against modifications to more meaningful things like cardinality / value type ?

[:db/add :db/ident :attribute/meta “something else”] is what surprises you?

This looks unintentional. You asserted something about a bootstrap entity (the db/ident attribute.) the second change doesn't actually know/check whether the implicit retraction is against a bootstrap datom, just that it involves a bootstrap entity

Asserting something about :db/ident itself seems odd to me. Was this intentional?

yes, we’re doing some things to maintain theta sketches on attributes in transaction functions to facilitate some interesting things (datalog optimizer and other features). would be happy to share more about that once we’re a little further along :). i was trying to add them to every attribute entity when i ran into this exception for the boot entities