Closed Hellblazer closed 1 year ago
Ok so looking at the solution, is the problem that of using fully random filler, and not sequence number. So sorting was not at issue here after all.
I'll have to think it through but this makes sense, will probably merge. Would be nice to address tiny comment points but other than that.
It is a sorting issue. The previous code would assign multiple random longs per millisecond, so they would sort in random order compared to creation order.
The fix is to see if the ms clock has advanced. If so, then get new random and g2g. If not, then increment the lsb of the current random.
It’s one of the recommended ways to deal with high volume uuid creation where there’s a lot in the same ms. Will doc that.
It is a sorting issue. The previous code would assign multiple random longs per millisecond, so they would sort in random order compared to creation order.
The fix is to see if the ms clock has advanced. If so, then get new random and g2g. If not, then increment the lsb of the current random.
It’s one of the recommended ways to deal with high volume uuid creation where there’s a lot in the same ms. Will doc that.
Yeah sorry, what I meant was that the problem was not in UUIDComparator
s implementation of sorting but -- like you explained well -- in not generating monotonously increasing additional sequence beyond 48-bit timestamp (originally just adding fully random bits which provides uniqueness but not ordering).
Makes sense, will merge & publish new version.
Correct implementation to provide monotonic sorting for V7 Addresses: #69