I guess it's more the case of '{::xt/tx-id tx-n}' being undocumented, and the ::xt/tx key expecting a whole transaction map with a ::xt/tx-id in it

yep that's pretty much the case, the ::xt/tx map (in turn containing ::xt/tx-id) is the official™ way to use the API

uuid is a generic choice for polymorphic documents (that is, a document can be of many types at the same time). Other options are using typed/namespaced compound keys like [:type id] or {:type id}. And yet another use key is using the id to force uniqueness, as a kind of an natural key like an email address of a user (do note that it would prevent people from changing their emails, so we make the address a separate document, with the email as id so that there is only one email address in the system, taking extra, super care to handle normalization with capitalization, + addresses etc)

Thank you for this

You're welcome

Hey, I think a UUID is almost always the best answer, unless: 1. you can be confident about avoiding collisions in the ID space - in which case a Long or short string may actually be okay (and probably is the most compact option!), or 2. you have an upstream ID - in which case use a keyword/map/string/URI can be a good idea

a map is an interesitng idea. I didn't know that was possible

The id is anything serializable, that's why UUID works too (so it's really the java object, not just a string that happens to conform to uuid spec)

If one weren't use use an identifier such as an email address. How would indexing work should I want to lookup a user via email address

All fields are indexed, though not deeply

What's the distinction there?

You cannot make efficient searches inside a value, that is a map, for example

Is space a concern being that "everything" is indexed?

Someone else will have to take that one

No problem at all. I really do appreciate both yours and @U899JBRPF’s input here

> Is space a concern being that "everything" is indexed? Ultimately, everything has its limits and you should definitely measure and experiment with your own realistic workloads. RocksDB does perform some compression of indexes though (which is tunable), and in general XT attempts to limit the amount of memory required to perform Datalog queries through lazy execution ...also disk is ~cheap 🙂 What size of data sets do you typically work with?

@U8ZQ1J1RR > Other options are using typed/namespaced compound keys like [:type id] or {:type id}. Out of curiosity, could you do a query of the sorts

{...
 :in [?id]
 :where
 [[?e :xt/id [:a-type ?id]]
 ...}

Easy to test that! And answer is no, you need to provide the whole value (the map) as the input

At the same time as I was testing, I noticed that I couldn't actually use vectors as ids, just "scalars" and maps 😦

Ignoring for a moment that vectors aren't valid ID types (so this exact example won't work), you can do this sort of thing though:

{...
 :in [?id-v]
 :where
 [[(vector :a-type ?id-v) ?id]
  [?e :xt/id ?id]
 ...}

{...
 :in [?id-v]
 :where
 [[(hash-set :a-type ?id-v) ?id]
  [?e :xt/id ?id]
 ...}

https://docs.xtdb.com/clients/clojure/#_entity

Oh! I didn't see that in the querying docs, my apologies. Is the eid the :xt/id?

(xt/submit-tx node [[::xt/put {:person/name "Alice",
                                      :xt/id "alice-1"}]])
  (xt/entity (xt/db node) "alice-1")
=> {:person/name "Alice", :xt/id "alice-1"}

Thank you much