This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-29
Channels
- # aleph (3)
- # announcements (29)
- # babashka (99)
- # beginners (30)
- # calva (46)
- # cider (9)
- # clara (1)
- # cljsrn (4)
- # clojars (10)
- # clojure (41)
- # clojure-dev (4)
- # clojure-europe (45)
- # clojure-nl (3)
- # clojure-norway (13)
- # clojure-uk (5)
- # clojurescript (61)
- # community-development (11)
- # cursive (10)
- # data-science (1)
- # events (1)
- # fulcro (17)
- # graphql (1)
- # gratitude (1)
- # holy-lambda (1)
- # jobs (4)
- # jobs-discuss (5)
- # meander (22)
- # off-topic (50)
- # pedestal (3)
- # re-frame (3)
- # reagent (3)
- # reitit (82)
- # releases (2)
- # rewrite-clj (14)
- # shadow-cljs (3)
- # spacemacs (14)
- # tools-deps (7)
- # xtdb (33)
Hi, What’s the query that finds all entity-ids in the database?
(xt/q (xt/db node)
'{:find [e]
:where [e _]})
won’t do.you were really close, this should get you what you want:
(xt/q (xt/db node)
'{:find [e]
:where [[e :xt/id _]]})
notice :where expects a vector of vectors while you supplied a single vector(xt/q (xt/db node)
'{:find [e]
:where [[e :xt/id]]})
Turns out the missing enclosing [] in whereIt 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
@U899JBRPF Curious about the #xtdb-id thing, when I run:
#xtdb/id "98947c1c08ece69c6f2c19c849c54d561843a789"
in the repl, it shows:
; 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")
?
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
I wonder if there is any simple way to atomically increment a value without using transaction function. The read-and-write pattern is so common, I wonder if we have write transactoin fucntions for each cases then the process would be quite tedious.
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 🙂)
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
> 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.
Hey, is it Possible to Store next to a transaction which user triggered it?
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