There is not. If you want histories, check out Datahike or Asami. Note this https://clojurelog.github.io/.

Have you tried the with-ops? option for open-tx-log or with-tx-ops? for listen?

Yup. The issue is that deletes have`:xt/id`s encoded:

([:xtdb.api/put #:xt{:id :put}]
 [:xtdb.api/delete #xtdb/id "9485989ff514b5106b7738850fd73c23e8c1e3f7"])

I think there is a valid argument here to do something more friendly, like replacing the #xtdb/id with the :xt/id wherever possible in these APIs :thinking_face: but essentially it's just surfacing the raw information from the tx-log, which is always hashed, because the log is truly immutable (unlike documents...which may be evicted and replaced with tombstones)

You can actually pass the #xtdb/id into entity to find out the :xt/id but that requires the db to intersect with a window when the entity is visible:

(with-open [n (xt/start-node {})]
    (xt/submit-tx n [[::xt/put {:xt/id :foo}]])
    (xt/submit-tx n [[::xt/delete :foo]])
    (xt/sync n)
    #_(with-open [t (xt/open-tx-log n -1 {:with-ops? true})]
      (into [] (iterator-seq t)))
    (:xt/id (xt/entity (xt/db n {::xt/tx-id 0}) (xtdb.codec/new-id :foo)))) ;;=> :foo

xtdb.codec/new-id is what is used internally to generate the hash

I just raised an issue https://github.com/xtdb/xtdb/issues/1769 🙂 feel free to chime in there!

Nice, thank you! I guess just decrementing the last tx-id may still place one out of the window (so to speak :))? Well, okay, you can just keep decrementing until entity returns something.

> eid is an object which can be coerced into an entity id. "entity id" here is the hash, correct?

Eeek, I see ::xt/fn ops are also conformed to the hash.

> I guess just decrementing the last tx-id may still place one out of the window ah yes, for sure, I just did that did in the example code to get something working 😅

> Well, okay, you can just keep decrementing until entity returns something to unblock you for now during development (tiny database sizes) that is probably not an absolutely terrible idea 🙂 better still, I can whip up some code to resolve #xtdb/id => :xt/id via internal APIs, but not until much later today/tomorrow

Fantastic, thanks.

Hey again, having now looked at the internals a bit and reflected, I think the function in this updated code is actually a pretty acceptable userspace solution for now, via open-entity-history (avoiding valid time window confusion entirely, not sure why I didn't think of that earlier ): https://github.com/xtdb/xtdb/issues/1769 It's not going to be exactly as efficient as a native solution, but is definitely not far off in comparison!

Thank you!