Please show the query you are doing, so it's easier to see the shape of the data too

(def node (xt/start-node {}))
  (xt/submit-tx
   node
   [[::xt/put
     {:xt/id :commodity/Pu
      :common-name "Plutonium"
      :type :element/metal
      :density 19.816
      :radioactive true}]

    [::xt/put
     {:xt/id :commondity/N
      :common-name "Nitrogen"
      :type :element/gas
      :density 1.2506
      :radioactive false}]

    [::xt/put
     {:xt/id :commodity/CH4
      :common-name "Methane"
      :type :molecule/gas
      :density 0.717
      :radioactive false}]])
  
     (xt/q (xt/db node) '{:find [name]
                          :where [
                                  [_ :common-name name]
                                  ]})
     ;; => #{["Methane"] ["Plutonium"] ["Nitrogen"]}
     

#{[{:id  :commodity/Pu :name "Methane" }] [ {:id  :commodity/Pu :name "Plutonium" } ] [ {:id  :commodity/Pu :name "Nitrogen" }]}

https://docs.xtdb.com/language-reference/1.23.0/datalog-queries/#pull

(->> (xt/q (xt/db node)
           '{:find [(pull e [:xt/id :common-name])]
             :where [[e :common-name name]]
             })
     (map first)
     (map #(clojure.set/rename-keys % {:xt/id :id, :common-name :name})))

Or

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

I should perhaps add you that you can use regular Clojure functions in your clauses to do things like this if really needed: [(hash-map :foo 1 :bar 2) ?map]

Thanks @tomi.hukkalainen_slac

;; with just 'query':
(xt/q
 (xt/db node)
 '{:find [?uid ?name ?profession]
   :where [[?user :user/id ?uid]
           [?user :user/name ?name]
           [?user :user/profession ?profession]]})
#{[1 "Ivan" :doctor] [2 "Sergei" :lawyer], [3 "Petr" :doctor]}

select uid,name,profession from node where uid=? or etc...

These particular :where clauses have no conditions other than an implied existence predicate, so the effect is only unification and projection. In other words "pattern matching" for only relevant entities that hold all the attributes simultaneously (with potentially many combinations of values)

The unification of ?user here is behaving more like a self join in SQL, but I wouldn't recommend attempting to reason about Datalog in terms of SQL operations too much when trying to learn Datalog

Yeah. In SQL you have tables, that define a scope. You can query all rows in a table, even without knowing what columns exist. Multiple tables might have the same columns you are interested in, or be even identical, but you cannot query for the columns without knowing the table(s). In datalog you query "columns first", in a way. That is, you know at least one attribute you are interested in, and then can get all objects/documents/"rows" that have that, even if they otherwise are different. Database is not the layer that limits the schema, unless you would consider transactions functions to be that (but whenever a client chooses to insert data using a transaction function, it might as well use any other schema mechanism and a plain put).

ok, thanks, maybe I need to read the documentation carefully and understand the usage scenarios of xtdb

Perhaps I misread, but there certainly are scenarios where XTDB is especially useful, but I wouldn't think that you need to have any special needs to gain a lot of benefit compared to SQL, or especially compared to "no-SQL" databases

If you feel uncertain about how you can even find the data you want, when anything could be in the DB, I certainly sympathize

In a way, xt/attribute-stats might help there. It lets you see what kind of things you could be querying for. And of course you can always query for documents that have :xt/id, i.e. everything

In actual deployed code, the queries would be limited anyway. Meaning that there's no practical difference between a SQL based system inserting and querying rows in a table, and a XTDB/datalog based system putting documents, and then querying the attributes it writes

Thanks. • I have never known about bitemporal database. so I don't know what kind of scenarios to use it in. Because I only have a background in rdbms usage

If you don't have a use for it, it won't get into your way. It lets you answer questions of type "Why did the system show in January that 2022 yearly report was A, but now it's showing it's B"

Oh, I understand a little bit

In SQL, you could perhaps fix that with thinking ahead, and adding a "data_added" column in addition to the actual date column. But handling all cases becomes a hassle

Hey @U0C8489U6 I hope all is well 🙂 I just posted your question onto Discuss and answered it there https://discuss.xtdb.com/t/will-large-xml-blobs-get-compressed/135 Funnily enough it also got discussed during the meetup lightly (though not XML specifically)!

All is well 🙂 I am watching the video as we speak 😉 Thank you!

one thing to note, if you store it as a string, then it will bloat your lucene as well (if you have lucene indexing)

I think this is a common question not just in XTDB but all databases… in basically every application I’ve had to contend with the “should I put files in the db vs external storage and store metadata”, in the cloud era I think S3 (and equivalents) is the usual solution