(xt/q (xt/db node)
        '{:find [e]
          :where [e :xt/id _]})

you were really close, this should get you what you want:

(xt/q (xt/db node)
        '{:find [e]
          :where [[e :xt/id _]]})

(xt/q (xt/db node)
        '{:find [e]
          :where [[e :xt/id]]})

right. thanks

It seems to me, when the end-time is earlier than the start-time, then the valid time would be [start-time, forever]

e.g,

(xt/submit-tx node
                [[::xt/put 
                  {:xt/id :asdf/asdf
                   :first-name :john}
                  #inst "2018-05-18"
                  #inst "2018-05-14"]])

  (xt/q (xt/db node #inst "2018-05-20")
        '{:find [e]
          :where [[e :xt/id]]})

yep, end-valid-time is simply used to put one or more nil records in the entity history, so it is essentially a noop from a query perspective to set it to a time before the start-valid-time. I expect you would still see the nil entry inserted at the appropriate place in the history if you look at the output from entity-history. Arguably XT could detect the faulty argument and reject the transaction before submitting it, but that's not how it works currently. If you're curious, see https://github.com/xtdb/xtdb/blob/e2f51ed99fc2716faa8ad254c0b18166c937b134/core/src/xtdb/tx.clj#L102-L115

Yes. I saw a nil result.

@U899JBRPF Curious about the #xtdb-id thing, when I run:

#xtdb/id "98947c1c08ece69c6f2c19c849c54d561843a789"

; Syntax error (IllegalArgumentException) compiling fn* at (.calva/output-window/output.calva-repl:0:0).
; No implementation of method: :id->buffer of protocol: #'xtdb.codec/IdToBuffer found for class: clojure.lang.Symbol

I'm not certain on how reader macros work at the repl, but does it work if you eval (identity #xtdb/id "98947c1c08ece69c6f2c19c849c54d561843a789")?

Yes. That works. What’s the benefit of using #xtdb/id reader macro?

I saw this now: https://github.com/xtdb/xtdb/blob/master/core/src/xtdb/codec.clj/#L536

Cool. Not sure on exact history, but I think it greatly aids testing and repl work for the core team

I guess for #xtdb/id “hex-string”, for example, helps to uniform upper/lower case represenatation of things like 0xAB, and 0xab.

I think it's more like having to avoid storing a bunch of binary in the test files: https://github.com/xtdb/xtdb/blob/e2f51ed99fc2716faa8ad254c0b18166c937b134/core/test/xtdb/codec_test.clj#L125

In short, no, you can only use transaction functions in these read-then-write cases, although I imagine that a utility lib with a suite of helpful transaction functions could be valuable for the community.

This got me confused. So for all “update” operations, a dedicated function is needed. It seems it becomes impractical to use xtdb for these use cases. Any example applications that use xtdb for reference?

Not necessarily, it depends on the semantics and consistency you want (e.g. you can use match + retries instead). In case it helps to know though, you can define and use a transaction function inline easily enough https://github.com/xtdb/xtdb/blob/e2f51ed99fc2716faa8ad254c0b18166c937b134/test/test/xtdb/tx_test.clj#L653-L664

Your transaction functions can also be super generic and reusable - you could create something like :eval-fn (though I'm not recommending that option, it only just occurred to me 🙂)

What do you mean by eval-fn?

inlining a function takes much repetitive storage for the function itself (dunno if it is a concern though, probably).

something like

[::xt/put {:xt/id :eval-fn
            :xt/fn '(fn [ctx form]
                      ((eval form) ctx)}]

Basically it is the same as writing an inline function as you still have to specify the form. Is storage ever a concern to you ?

since arg-docs get replaced by their evaluation, this might not actually be completely crazy as a way to efficiently (storage-wise) do things inline :thinking_face:

> Is storage ever a concern to you ? Of course(!) Although I don't like to constrain ideas & suggestions too prematurely

How big is your data set?

> since arg-docs get replaced by their evaluation, this might not actually be completely crazy as a way to efficiently (storage-wise) do things inline Are you saying, not only the function invocation argument (i.e., the [::xt/fn xxx]) part could be replaced with the actual transaction function output, but also the inline transaction function itself can be safely erased since we already get the output. This indeed is an optimization.

Yep, exactly that 🙂

Hey @U02DYDLDZGE not as a first-class API, but you can store this information in an additional document each time (e.g. :tx-meta-entity) and correlate the transaction time(/id) when querying, or you could use a transaction function to embed the transaction time(/id) inside that that entity

There are perhaps other use-cases for a first-class API in future though, see https://github.com/xtdb/xtdb/issues/253