I don’t know anything about how this performs on axon server, but if you propagate this to any database that would be using a btree index on it this would perform horribly at scale. While I think this is fine if you point out that it’s for the example and that you don’t recommend anything other than UUID 7 for databases at this time… note: personaly I’m using GitHub - f4b6a3/uuid-creator: UUID Creator is a Java library for generating Universally Unique Identifiers. It generates all standard identifiers from UUIDv1 to UUIDv7. It also provides an alternative to the classic JDK's UUID (alt.GUID), many codecs (codec.*) and several utilities (util.*). but you could just not give a recommendation. I’m bringing this up simply because I see regular storms of “UUID for databases bad” usually followed with “not if you use a time ordered uuid” and of course… well it’s in production now and we have 50 million ide’s than need recreating.
public static CourseId random() {
return new CourseId(UUID.randomUUID().toString());
}
personal opinion that a comment about this would be a good idea.
2 Likes
Loving the suggestion, @xenoterracide! Would you, perhaps, be up to contribute this helpful pointer to our documentation? If you’re not, feel free to state that as well. This is by no means a push.
I just think you deserve the credentials to be marked in Axon’s commit log 
I could, but I think I’d need more information
- Does Axon Server suffer directly from the same problem at scale?
- Do you want an actual library recommendation?
I do not know what you would do to remediate this without a 3rd party library, for example postgres you would consider a bigserial from a sequence… and I think postgres is or recently got support for UUID 7, but even so, I wouldn’t know how you’d recommend handling this problem in the Axon workflow.
Basically, while I can easily write “don’t use randomUUID in production”, that doesn’t help people actually remediate (which might be it’s own full article but I don’t feel qualified to write just yet).
1 Like
Let me reply to your two pointers there, @xenoterracide:
- Does Axon Server suffer directly from the same problem at scale?
No, I have not seen it face issues with this at all, nor do our tests point into that direction.
- Do you want an actual library recommendation?
No, not necessarily either.
What I think would be beneficial is to have some form of note or tip (AsciiDoc has dedicated blocks for that) suggesting that it is wise to think about ID generation, as some solutions down the users line may be impacted greatly by it.
1 Like
No, I have not seen it face issues with this at all, nor do our tests point into that direction.
Just so you know that this is a hardware dependent problem and so it’s something like hundreds of millions maybe even billions beyond that before a btree index is going to start showing slowdowns on inserts. So I doubt it’s going to show up unless you’re testing for it. I don’t know what all kind of indexes it does but It would affect any btree. A btree basically wants sequential inserts or it spends a lot of time looking for where something needs to live in it’s index. I am certainly not the best person to explain the math and other actual problems behind this.
I’ll take a shot at writing this up sometime this week obviously not all the detail I put here.