Fork me on GitHub

Typo in the docs? db-basis map should be ::xt/tx-id instead of ::xt/tx


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


Newbie question: What are people generally doing for xt/id. Does it make sense to use a uuid here?


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

🙏 1

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)

😎 1

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?

Nikolas Pafitis08:04:06

@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]
 [[?e :xt/id [:a-type ?id]]
in a destructuring manner?


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]
 [[(vector :a-type ?id-v) ?id]
  [?e :xt/id ?id]
And with map IDs (which are valid):
 :in [?id-v]
 [[(hash-set :a-type ?id-v) ?id]
  [?e :xt/id ?id]


Is there the concept of "entities" or does everything need to be specified in the pull expression? Sorry if I'm using too datomicy terms


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

✔️ 1

(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

👍 1
plus_one 1