@U1LR4AN75 • api-ms represents the time spent processing the transaction including tx-with time. • msec is the transactor time or everything that can be measured from the transacting process (i.e. everything but interprocess communication). • apply-msec in the context of a transaction is functionally the same as api-ms, I would not rely on this number outside of a support context. We have a future metric coming down the line which will show the Total apply-msec of transactions over 1 minute (process monitor log). https://docs.datomic.com/pro/api/io-stats.html#relating

Ok I have changed the function so it takes everything from transaction and now it contains only changed attributes:

(defn find-history
  [db request]
  (->> (d/q '[:find ?tx ?attr ?value
              :in $ ?e
              :where
              [?tx :db/txInstant _]
              [?e ?attr ?value ?tx true]]
            (d/history db) [:request/id (:request/id request)])
       (map #(->> %
                  (map vector [:tx :attr :value])
                  (into {})))
       (group-by :tx)
       (map (fn [[tx xs]]
              (reduce (fn [acc {:keys [attr value]}]
                        (let [attr-ident (d/ident db attr)
                              value (if  (= :request/state attr-ident)
                                      (d/ident db value)
                                      value)]
                          (assoc acc attr-ident value)))
                      {:tx tx}
                      xs)))
       (sort-by :tx)))

supply attrs as input?

This what you want?

(->> (d/q '[:find ?tx ?attr ?value
            :keys tx attr value
            :in $ ?e [?attr ...]
            :where
            [?e ?attr ?value ?tx true]]
          (d/history db) (find request :request/id) [:request/state])
     (sort-by :tx)
     (into []
           (comp
            (partition-by first)
            (map (fn [xs]
                   (into {:tx (:tx (peek xs))}
                         (map (juxt :attr :value))
                         xs))))))

You don’t really need query here either, (d/datoms history-db :aevt attr entity) gives you the same

off-topic: (find request :request/id) => [:request/id 123] 🙂

@U09R86PA4 I wanted to achieve that result will be list of transactions where at least :request/state was transact and in each transaction I want to include all changed attributes

So request/state changes tells you what txs to inspect, then you want everything from that tx?

If so then the second phase should use the tx log

Or maybe not? Maybe you just want what changed on that entity?

Either way, d/ident is the fastest way to get a keyword of an attr if you have a number. The greater concern is whether your queries are fast, clear, and correct

For example, if you just want what was asserted with transactions which also asserted a change to request state, this may be better (assuming all attrs are card-one):

(->> (d/q '[:find ?tx ?attr ?value
            :keys tx attr value
            :in $ ?e
            :where
            [?e :request/state _ ?tx true]
            [?e ?attr-id ?value ?tx true]
            [(datomic.db/ident $ ?attr) ?attr]]
          (d/history db) (find request :request/id))
     (sort-by :tx)
     (into []
           (comp
            (partition-by first)
            (map (fn [xs]
                   (into {:tx (:tx (peek xs))}
                         (map (juxt :attr :value))
                         xs))))))

However if you want what the entity looked like before or after request-state transaction (i.e. including attrs that didn’t change), then you’re doing a pull with d/as-of on each tx you find.

or if you want everything that happened in the tx to any entity, you want to use tx-range to get the log entry for those txs which had request state changes

Downgrade your jvm then try again and post the stack trace of that doesn’t answer what’s going wrong

May worth to mention: Ions run on https://docs.datomic.com/cloud/ions/ions-reference.html#jvm-settings, in case you ask "which JVM I should run?" Hope that is enough to fix your issue! 🤞

I'm actually not worried about what the error is, I'm more interested in solving the unmarshalling error, in general. I was hoping it wouldn't involve downgrading my JVM.

@U087E7EJW check the bottom section of this page for flags to pass to the jvm on startup to bypass this issue if you can’t change jdk versions. https://github.com/aws/aws-sdk-java#maintenance-and-support-for-java-versions

tried that previously: Unrecognized option: --add-opens java.base/java.lang=ALL-UNNAMED

added to my deps' :jvm-opts