mlasevich
commented
10 months ago Honestly, while I see your point, I do not think it will be an improvement:
Core reasons to not do it:
1 - This implementation mirrors other implementations of the RSMQ. Consistency has value. 2 - Using UUID will increase storage requirements (36 bytes vs 30 bytes per id) 3 - Using UUID will increase probability of collision, UUID4 gives you 128 bits total (including timestamp) vs current implementation gives us (almost) 132 bits of randomness PLUS a usec timestamp
On the other hand:
1 - UUID is a more standard way to do this in general, even if it is not consistent with what other RSMQ implementations do 2 - I need to look into it a bit more, but I believe while consistency is nice, I am pretty sure it is not required for interoperability with other implementations 3 - Extra 6 bytes per record is not that big of a deal 4 - Collision probability, while different, is mostly academic, UUID collision maybe more probable, but the difference is negligible and the world agrees that UUID is good enough.
In the end, lack of notable benefit combined with inconsistency with other implementations make me say it is probably a waste of time - however, if you really want to, maybe we can make this a selectable option, so that if someone really wants to, they can choose a UUID generator in place of a standard one.
HTH
Hello Team,
This looks like a wonderful project, kudos to the developers who developed this. I see we are using random str for message_id, rather than using random string i suggest we can use uuid4, to achieve more randomness in the id. UUIDs (Universally Unique Identifiers) are designed to be globally unique across space and time. The probability of generating the same UUID is extremely low.
If you agree on this, I would love to contribute to this project, please let me know your thoughts on this suggestion