The most commonly used for IDs is type 4

The ones that are more "human friendly" are going to be less unique due to less bits available for the randomness. They may also require additional logic to handle. Generating type 4 is trivial and is included in Java.

Yep, type 4 is definitely a good default 🙂 Main thing for XT2 is to use UUID objects rather than strings (the former we store as 16 bytes, and use it directly for our internal IDs; the latter we store as a string and have to generate our own internal ID - i.e. avoid the prefix 🙂). Also to ensure that they're well distributed - type 4 are good for this out of the box; 3 and 5 are hashes so these work well too if you want to generate them from a natural key. 7 and 8 are also acceptable but you're more in charge of making sure they're well distributed.

there are some articles out there discussing why uuids are wrong for db keys. If I remember correctly the argument was more about uniformity of distribution. generation time and such things. Alternatives: ulid, nanoid, https://github.com/hden/cuid2 The choice is yours of course.

Yep, agreed, it's important to use them in the right contexts and not in the wrong ones - there are plenty of databases where they're the wrong choice, as you say. In the case of XT2, though, the primary index has been chosen/designed so that UUID v4 (or any other well-distributed UUID version) works best 🙂

Particularly, it's preferable not to use string IDs (like ulid, nanoid, cuid) in XT2 (unless they're natural keys) for the reasons above

It's good to know

While probably very inefficient, can build a uuid UX similar to git, where given the first few chars of a uuid I could find matching xt/id ? Using v2

we probably could, yeah - good idea 🙇 not even sure it'd be that inefficient, they're stored sorted already

we'd have to do the collision detection, same as git, but I doubt that'll set the profiler on fire

interesting 🙂

Looks like I revived discussion. I'd say sorry but good discussion should go on I guess 😇

with a number key the error becomes invalid struct key: '1' but it works with a string key

hey @U797MAJ8M 👋 thanks for the report I wonder if it's related to https://github.com/apache/arrow/issues/40773? :thinking_face: If so, it'll be the keyword value causing issues - could you swap :macvlan for a string to confirm? If that works, then yep, it's another one we'll raise upstream with the Arrow folks 🙂

yeah it works as a string -- meant to say string value above, not string key

cheers - raised as https://github.com/xtdb/xtdb/issues/3305