Fork me on GitHub
#xtdb
<
2023-02-11
>
eighttrigrams15:02:49

Hey, can I search for a field across time? For example if I have one entity which I first create and then I update later on, like 1. {:xt/id 1 :field "A"} 2. {:xt/id 1 :field "B"} . Now, let's say I want to get all records in the whole db where :field is "A" , but I do not specify a time, but nevertheless I want to retrieve the :xt/id 1 entity as a result. Is this possible?

jarohen14:02:54

Hey @U03GYEFN2U8 - this isn't possible as it stands, I'm afraid, but it's certainly something we'd like to do - it's on the roadmap 🙂

eighttrigrams08:02:35

Hey @U050V1N74, cool, good to know 🙂

eighttrigrams16:02:23

On another note, I would like to get all entities where my search term is contained in one of the entities' fields (which always is a collection). From examples in the documentation I was able to figure out a way to do this.

(xt/submit-tx xtdb-node 
              [[::xt/put {:xt/id 1
                          :field ["LM" "N"]}]])
(xt/sync xtdb-node)

(xt/q
 (xt/db xtdb-node)
 '{:find     [(pull ?e [*])]
   :where    [[?e :field field]
              [(identity val) field]]
   :in        [val]
   }
 "LM")

#{[{:field ["LM" "N"], :xt/id 1}]}
However, I have difficulties understanding the meaning of the [(identity val) field] line. How does one read this? Or, in which way does this translate into or correspond to a filtering expression?

jarohen14:02:15

this is a function call - it calls (identity val) and binds the result to the logic variable field , which then constrains the values of the other occurrence of field in [?e :field field] . in this case, though, it shouldn't be necessary (although I'm away from a REPL right now!) - you should be able to run {:find [...], :where [[?e :field val]], :in [val]}?

eighttrigrams08:02:29

What I still do not get is why one needs to write (identity val) instead just val. In any case, when I comment out the whole line [(identity val) field] then it does not do what I wanted it to do, namely only getting me the first record:

(xt/submit-tx xtdb-node 
              [[::xt/put {:xt/id 1
                          :field ["A"]}]])
(xt/submit-tx xtdb-node
              [[::xt/put {:xt/id 2
                          :field ["B"]}]])
(xt/sync xtdb-node)

(xt/q
 (xt/db xtdb-node)
 '{:find     [(pull ?e [*])]
   :where    [[?e :field field]
            ;;   [(identity val) field]
              ]
   :in        [val]
   }
 "A")

# Output:
{[{:field ["A"]
   :xt/id 1}]
 [{:field ["B"]
   :xt/id 2}]}

jarohen09:02:36

@U03GYEFN2U8 this is because you now have two distinct logic variables (`field` and val), which are not unified, so you'll essentially get an unfiltered query. could you try the query in my previous message?

jarohen09:02:50

> What I still do not get is why one needs to write (identity val) instead just val. this is because [val field] alone would be invalid syntax. we have the ability to call functions and bind their results to logic variables - this is saying 'call (identity val) and bind the result to field ', but it could be any other function too (e.g. [(str "field-" val) field] - 'find me all the documents with a :field of "field-A" ')

jarohen09:02:36

but, as I say, the easiest way to ensure that two variables are equal in Datalog is to use the same variable name

eighttrigrams09:02:24

| could you try the query in my previous message? oh, i see, you are right,

(xt/submit-tx xtdb-node 
              [[::xt/put {:xt/id 1
                          :field ["A" "C"]}]])
(xt/submit-tx xtdb-node
              [[::xt/put {:xt/id 2
                          :field ["B"]}]])
(xt/sync xtdb-node)

(xt/q
 (xt/db xtdb-node)
 '{:find     [(pull ?e [*])]
   :where    [[?e :field val]]
   :in        [val]
   }
 "A")

;; Output:
#{[{:field ["A" "C"], :xt/id 1}]}
this works! would not have expected that the query would match values within collections, but i am fairly new to datalog ..

eighttrigrams09:02:08

thanks for the explanations 🙏

jarohen09:02:54

cool, no worries 🙂 any other questions, give us a shout

đź‘Ť 2
Oliver Marks19:02:24

I am running some xtdb queries in quick succession, ie many requests hitting jetty and each one running a query, I can dump out the queries and see that each has a different xt/id but the resulting documents all have the same xt/id, I am using the rock backend locally any one seen this behavior before ?

jarohen14:02:48

Hey @U02DXJUS5JA - I've not heard of this before in XT. If you could open an issue with even an intermittent repro it'd be much appreciated 🙂

Oliver Marks14:02:28

could be something I have done, I imagine it would be tricky to reproduce I will try a few things more things and see if I get any where, always worth an ask though 🙂

tatut06:02:16

only time I remember having “wrong” results was when the local indexes and the golden stores “didn’t agree”… like emptying the golden stores but not the checkpoints

tatut06:02:24

but that sounds very weird indeed

âž• 1