I vaguely remember someone else talking about this a few months ago and a datomic rep said it was a known limitation or something

to get the idea of what I'm going for is given two people

Name | ArbitraryField | Id
Bob    | A123               | 1
Steve | B321                | 2

I'm also fine with it returning something like

[[1 [:name]] [2 [:arbitrary-field]]

Datomic works with set so you will have to associate the score to each result yourself with something of this shape:

(or-join [?name-q ?arbitrary-q ?id ?points]
         (and [?id :name ?name-q]
              [(ground x) ?points])
         (and [?id :arbitrary ?arbitrary-q]
              [(ground y) ?points]))

ah that's exactly what I'm looking for, thanks

There’s not enough space for a universal uniqueness in 64 bits (that’s why all versions of UUIDs are 128 bit). Datomic likely uses the fact that all the new entity ids are generated sequentially (due to sequential transactor), so it could guarantee uniqueness via counters and/or clocks.

I’d go with tx function which uses aggr max / index lookup + ensure attr has an AVET index. This should yield an O(1) / O(log n) time complexity. Query first approach would require CAS.

And it would probably be more efficient to go down by negative ids, this way index lookup would require to realize only the head of the lazy index: (dec (first (index-range db :your/attr nil nil)))

Clock value (micro/nanoseconds) should also be ok in tx function due to sequentiality of txs (but not precalculated as tx data, as those are not sequential). IIRC they used it in Crux for :db/ids. And it probably worth mentioning that both approaches generate ids which are easy to guess by 3rd-party (not to say UUIDs are too hard to guess but still).

insightful, thanks, taking notes