You could run it by yourself on google cloud, but it will have to be datomic on-prem, that you manage, and not datomic cloud

Or you could return the tx id from the query and pull later

Or you could create an as-of db and use it as an argument to a sub query

Could you be more concrete about the desired input and output you want? Tx is available to datalog so with some range filtering you can do some things in one query, but I don’t know if it’s worth it without a more specific problem

@U09R86PA4 ^^

[?e ?a ?v ?tx ?added] clauses don't look at every tx, only those which involve ?e ?a ?v. I think you need a concrete example (some code) to suggest something more concrete

it could be that you can't do what you want efficiently, but we're talking too abstractly for me to say for sure

maybe you could make a stackoverflow question?

yea, honestly i didn't really understand [?e ?a ?v ?tx ?added] clauses. where can I find more information on that?

also, i can create a concrete example if I explore the provided material and still have an open issue.

but it does sound like my answer will lie in understanding that clause.

datomic is datoms

datoms are a tuple: [entity-id attribute-id value tx-id assert-or-retract-bool]

datalog clauses are datom pattern matches

this may help:

http://tonsky.me/blog/unofficial-guide-to-datomic-internals/

the maps are an illusion

it's datoms at the bottom

and "time travel" is filtering datoms by tx

ok, thanks!

one question: for a typical clause [?e :some/attribute ?some-value]: is this just a truncated form of the [?e ?a ?v ?tx ?added] clause? i.e., are ?tx and ?added optional? also what exactly does ?added mean, is it true for only the single point in time where an association is originally made?

[and false at all other times]

Omission is truncation

Ie match anything

Added is true when the datom is asserted, false when retracted

You will only see “false” in history dbs.

👍:skin-tone-2: